Web Application Development – Top 3 Principles
Everybody has problems. As web developers, we are trained to find solutions using technology. I submit to you that the most important things (all great lists come in threes) when solving a web problem are:
- Simpler is better
- There is always a way
- Passion overcomes intelligence and skill
Simpler is Better
I’m convinced that the concept of “bigger is better” does NOT hold water. Bigger isn’t always better, especially in web applications. Software naturally gravitates to code bloat because buyers are always asking for more functionality. How many times have we heard, “I need it to do this” or “we are unique”. Yeah, right.
WARNING: The next few paragraphs involve an old geek reminescing.
I remember my early days with PCs: DOS 1.0, Visicalc, WordStar, Lotus 1-2-3, MultiMate, dBase, Symphony, etc.
DOS was successful because it was cheap and simple. Gates may not have produced (or bought) the best technology, but he almost always had superior marketing (until Vista). The operating system was a dumbed-down version of Unix. Even a novice like me could quickly master it. And giving it to PC manufacturers for $10 a copy was genius. IBM announced its version of UNIX in January 1984 priced at $900! History shows who provided the better software. UNIX most certainly was more robust (I hate that term), but it wasn’t BETTER because it wasn’t what people needed.
Lotus 1-2-3 had about knocked-off Visicalc by the time I graduated college in 1985. In their “bigger is better” wisdom, Lotus created Symphony. Combining spreadsheet with word processing, database, and communications was the rage. Ashton-Tate quickly followed suit with Framework. But all of these types of packages had price tags over $700 and lost the focus on what made them successful. They were complex, hard to use, bloated, and expensive. They died fairly quickly.
Again, Microsoft drove the market through easier and cheaper. Word 2.0 had probably half the features of WordPerfect (the defacto standard at that time), yet it only took a few years to make WP a non-factor. Lotus 1-2-3 was cool stuff, but Excel was much less expensive and did everything I needed for rows/columns, so I bought it. PowerPoint bumped off Harvard Graphics. If you don’t trust my memory, Ken Polsson has an interesting site for the the Chronology of
Personal Computer Software.
Please don’t think I’m a Microsoft bigot…I’m not. My Mac runs NeoOffice just fine. I love not paying anything for it, my documents are formatted properly, my presentations look great, my spreadsheets are accurate. It’s just a download away (free). As far as I’m concerned, Office 2007 is doomed with all of its clever new toolbars. What a pain. Over-engineering, feature bloat, and the need to sell a new version for more money will be the bain of MS’ flagship.
I could say the same about Webex in favor of something like Gotomeeting.com. We were an early user of Webex and there were so many disconnected features cobbled together that it made my head spin. All I needed to do was share my desktop and display slides. Webex was positioned as the top-of-the-line and their sales reps were very proud of it. We dropped it in favor of some simpler, easier, cheaper conferencing software.
The local Microsoft regional managers held an annual pow-wow in Beaver Creek, Colorado a couple of years ago and they invited me. What was surprising to me was how Google was the focal point of all their strategy. It became very clear to me when speaker after speaker made presentations showing how they would beat Google at this, overcome Google at that, and sue Google if such and such happened – their #1 enemy was a search engine company, not Apple or Oracle or IBM or Sun or SAP.
Why? Because Google was giving away functionality on the web that had been the space MS dominated for two decades. Google Docs gives you easy and free word processing, spreadsheets, and data management. Sharing the files with others is so effortless. Google’s application platform and development tools didn’t require Windows. Google created its own browser capable of making the IE lawsuits by DOJ irrelevant.
Google had figured out that simpler is better for software. Lower cost solves real problems. Easier to use is a winner. More features creates confusion. Bigger software is not the best solution.
If bigger software was always better, I would still be compiling COBOL on a water-cooled MVS machine. It took hundreds of thousands of custom written lines of code to do what I can now get in free libraries, on someone’s website, or with an open source app.
Just like Craig’s List, the Flip video camera, the MP3 file format, the MQ-1 Predator, and Kaiser Permanente microclinics, we knew there was a simpler solution to the load testing problem. Success based on making things EASIER has been proven.
There is Always a Way
At CustomerCentrix we have built web applications since 1999 (wow, ten years have flown by). One of our biggest challenges was to load test our systems and tune them for optimal performance. It was embarrassing when our client, Alltel Corporation, had about 15,000 people hit our e-learning app at the same time. Our system melted down.
Stress testing really shouldn’t be conducted by your clients! But there we were. We couldn’t afford to buy a 20,000 user license for one of the enterprise solutions – we tried. The $150k price tag for LoadRunner was beyond us.
Our approach was to start with the assumption that there WAS a satisfactory solution, even though we didn’t know what it was, or how we would get there. However, our team WOULD figure it out. The solution WAS out there, and there was a way to make it happen.
Roger altered my paradigm when he gave me a copy of the book “Getting Real” by 37signals. It was a tremendous eye-opener for me. I loved the concepts of building less, staying lean, work from large to small, your app must take a side, and start with no. The following quote from the book sums it up pretty well:
“Beware of the ‘everything but the kitchen sink’ approach to web app development. Throw in every decent idea that comes along and you’ll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.”
37signals reminded me of the Pareto Principle and to apply it to software. Doesn’t software deliver 80% of its value through 20% of its features? Aren’t about 80% of features unused by most customers?
Those thoughts helped strengthen our resolve and changed our thinking about “there must be a way.” The “way” was modified. We no longer needed to build a battleship – we merely needed to build a very effective speed boat.
Armed with the pragmatic simplicity of “Getting Real” and our optimism, we didn’t let our “baggage” stop us from working on a better load testing tool. Our baggage included false starts, late deliverables, un-accomplished goals, and bogged-down projects. These development shortcomings could have jeopardized our confidence, conviction, and drive. But we knew there must be a way.
Like Edison, Colonel Sanders, the apostle Paul, and so many others that inspired us, we persevered. They knew there must be a way to achieve their objectives. They could see in their minds eye how the world would look when they realized their vision. Similarly, LoadStorm is a reality because we never gave up. We could see the speed boat racing across the water. We could envision the cloud ramping up hundreds of virtual servers to generate massive traffic loads.
We were driven because we knew we needed a solution. More importantly, we knew that the traditional enterprise software options were overkill. We didn’t need all those thousands of features. Not only was the price tag unbearable, but the learning curve was too. We needed load testing results without setting up additional servers, configuring software to run, taking classes on new scripting languages. There must be a way, and the way everybody else was doing it wouldn’t work for us.
Too often web developers’ optimism can digress to skepticism. Their bucket for tolerance of setbacks, willingness to forge ahead against the wind, and fear in the face of difficultly is “filled up”…and there is no room in a filled bucket for innovation.
So we emptied our buckets. We believed that a simple and elegant solution existed. We had faith that “there is always a way” and that we would implement it.
We believed there could be a relationship between reducing cost, streamlining functionality, and increasing customer satisfaction. The search began for the 20% of features that helped a load tester answer their questions 80% of the time.
Passion Overcomes Intelligence and Skill
We know we aren’t the smartest guys on the planet. It is obvious that some of the young guns coming out of school have better skills with web technology. There’s no use kidding ourselves.
What we DO have is an unrelenting passion for making people happy. It isn’t so important to us that we have extensive marketing research about the preferences of load testing gurus or performance engineers. Our zest for living is sparked by hearing a customer say, “Thanks man! You have made my life easier. I may get a raise out of this.” We realize that removing obstacles for web developers makes us happy. That drives our passion. They are like us, and we love finding a cool tool.
Passion is born of focus. Having your priorities clearly defined by nothing more than being yourself – that’s passion. Getting energized every morning coming to work because you get a rush out of putting pieces of a puzzle together to make somebody happy – that’s passion.
We didn’t invent the Internet like Al Gore. We aren’t rich like Bill Gates. We haven’t served the ultra-poor like Mother Teresa. However, we show up at the office every day because we sincerely want to make a difference in the lives of load testers and web developers all over the world. Especially the folks working hard on their dream in their own small office somewhere. We can relate to that.
Passion drove us to look for common elements between load testing obstacles, web development costs, and customer satisfaction. One such example was the “ease of just getting a graph showing concurrent users and response time.” Most developers we know aren’t performance engineers – they only need to get an answer.
Not only did we want to solve our own problem, we knew that there is a world full of people like us. Geeks that are under pressure to make the code work. Dilberts that have pointy-haired managers holding them accountable for web performance while giving them virtually no budget for load testing. Marketing managers that don’t care why the site is slow or what tools you are given, but you better not screw this up because they have a $100,000 campaign at stake.
The image of a geek smiling over his load test results gets us excited about making the best load testing tool we can, as simply as we can for as cheaply as we can. Because without us, he won’t get those graphs and charts, nor will he have weapons against the hassles of site meltdown.
Passion pushed us to ask our developer friends what they needed. What load testing problems did they face? What were the most challenging aspects of getting the web performance they need? Their answers (most of them) are built into our load testing tool.
Hopefully LoadStorm will give you answers to your load testing questions. And we want to hear from you about how to make it better. Do you have a passion for high-performance web apps? If so, will you share it with us?
What can you suggest as a needed feature in our load testing tool? When did you not answer a performance testing question with LoadStorm? Do you have innovative ideas?
We will pay you for your thoughts. Please submit your suggestion in our Feedback Contest, and you may win some money. We are giving away $400 to get real feedback from real users.
Please claim your share of the prize money. Help us refine the 20% that delivers 80% of the value.