SAN FRANCISCO, CA, USA, MARCH 11, 2010Ten years ago this week, the tech-heavy Nasdaq stock exchange reached its all-time peak of 5,048.52. It was the height of the dotcom boom, and thousands of developers were busy writing millions of lines of code for applications that wouldthey hopedrevolutionise computing and become mainstays of the Web. So where is all that code now?
Building applications for today's Web is a lot different than it was in those early days. Gone are the costly, monolithic e-commerce engines and content management systems written in C/C++, largely replaced by open source alternatives in more agile languages, such as Java and PHP. Meanwhile, once-promising technologies such as Napster and server push have joined Flooz, Geocities, and Kozmo.com as so much scrap on the side of the Information Superhighway. Remember ColdFusion?
As in any industry, much of the change has been evolutionary. But when platforms evolve, they often outpace the applications that build on them. Java, for example, is one of the more important technologies to come out of the dotcom era, but modern Java EE applications bear little resemblance to early, servlet-based code. Similarly, code compiled for a dotcom vintage Linux probably won't run on a modern server. Even the Apache Web server has undergone a major architectural redesign since the Nasdaq peaked in 2000.
What this means is thatin contrast to enterprise applications, which often keep humming along on decades-old legacy serversmost of the code written for the early Web has simply disappeared. It's been retired, rewritten, or taken out of service when the company that hosted it folded.
On the surface, then, the Web sounds like a massive productivity sink. All that work, all those hours to develop all those applications, and what do we have to show for it? But rather than crying over spilt milk, if developers learn the lessons of the last 10 years, they can gain a better understanding of how best to do business in the modern Web era.
First lesson: Emphasise agility
First, it seems clear that a successful Web project must be agile. "Ship early, ship often" is an oft-cited mantra from the open source world, and it works for Web apps, too. If we accept that real-world Web code seldom endures as a monument to its developers, there's no reason to fall victim to overengineering in the early phases of a Web project. As Joel Spolsky says, "Shipping is a feature. A really important feature. Your product must have it." For startups in particular, the ability to bring a product to market quickly often outweighs loftier engineering considerations.
That doesn't mean you should skimp in areas that could affect security or your user's privacy. In today's business climate, those kinds of missteps can be fatal. But scalability, for example, is one area that's often given too much focus in the early days of a Web project. In some cases it can be more prudent simply to plan to rewrite your application for scalability at a later date, rather than delaying the first version while developers dicker over architectural issues.
Sign up for MIS Asia eNewsletters.