How Web 2.0 Is Killing Software Development

It may seem like I'm awfully negative about Web 2.0, which isn't the case. I'm generally very excited about a lot of apps and a lot of companies, but lately, it's been the dumb things that really bother me enough to write about. Today, it's the realization that the entire set-up is killing the software development process.

Sure, it's been almost 10 years since I did any serious development other than poking around in things, but I know that the main tenets of programming haven't changed that much. An alpha should still be an alpha. A beta should still be a beta (sorry, Nick Bradbury). There should still be this silly little idea of a staging environment so that you don't push out an update only to find that it doesn't work. And scalability isn't something you should have to hire a separate person for.

Web 2.0 has lowered the bar for starting a company. When it took a huge amount of capital to get something off the ground, investors would push for someone with experience to be the CTO, and would push companies to hire proven software architects. With Web 2.0, two people can get together and bootstrap a company long before they ever contemplate taking on investors, and retain lofty titles like CEO and CTO based on the company's initial successes.

The problem is that when all you've ever been is a CTO or a co-founder, you are missing something crucial: life experience. If you've never worked for someone who's built an enterprise system that scales over millions of transactions, you are reinventing the wheel each and every time. There's a reason why the people in CTO positions in huge software companies usually are older, and have been around the industry for a while: they have experience. They've learned from others as well as their own mistakes, and can apply that experience to not creating problems in the first place.

There is no need for a company to hire a "scaling engineer." No such person actually exists. What they need to be hiring is a CTO who has the skills and the experience to have built something right the first time. Software best practices shouldn't be implemented after the fact.