My last post seems to have generated some commentary, as was intended. I moderate all comments and if you haven’t posted before it might take me a while to approve your comment. Once you’ve had one comment approved any future comments should appear immediately. I’m doing this is so I can filter out Viagra spam and it’s really in everyone’s best interests.

Internet script kiddy “you fail, loser” comments do not further the discussion and I will delete them. I’ve let everything through so far, since I didn’t set any ground rules, but I’ll be less lenient in future. Please limit yourself to mature responses that contribute something other readers might find interesting. Anything else will be deleted—you’re wasting your time posting that kind of thing here.

Please use your real name when you post (not that I can actually check who anyone really is). Anonymous posts will be consigned to the bit-bucket in the sky. Feel free to enter a fake email address, I don’t think WordPress actually uses them for anything. Thanks!

Facebook should have fired their development team the minute they became successful. If you’re a startup and you just made it big you should take a long hard look at your software team and make some changes.

I’ve worked for two startups and consulted at several more. I’m not just talking about software startups, this applies to many industries—transportation, web 2.0, shopping, digital media, government—where the guys who built v1 of your web site, order tracking software, customer service tool, batch processing system, whatever, are unequivocably not the people you should rely on to take you from Startup to Enterprise.

When you’re a startup, time-to-market and user base are absolutely the most important success factors. For an aviation startup, flying your planes, selling your tickets and generating a loyal customer base are the most important things. As a computer manufacturer, you hire ex-military types to run your logistics and can custom build a PC and get it to a customer’s doorstep in four days. In general, an IT/programming competency is not required for a startup to be successful. In fact, “enterprise” engineering practices can actually slow you down. As someone who’s written software at startups I know the pressures to get the next demo ready, to release the next feature for the web site. At that stage in the life of a startup we don’t even know if the company will survive another month. Heavyweight testing, deployment and release processes just slow you down. I’d argue that most development teams actually do the right thing at this point. Get the software done, fast, and make it mostly work.

The problem I’ve found when working at startups-turned-enterprises is that the guys who built v1 of that web site are now running the IT department. The operations guy who originally managed the company’s one web site is now in charge of your entire data centre. The v1 codebase has been hacked and patched into v2 and v3, and everything is in a mess. Let’s talk about the codebase. When trying to get stuff out the door as fast as possible developers will often find out that a design decision they made is no longer appropriate. Given enough time they could fix that problem, but they don’t because the demo is happening tomorrow. And this is the right decision! But letting that patched, hacked, copy-and-pasted codebase live any longer than it takes for the company to declare itself stable is a really bad idea.

Most software developers don’t know how to engineer large enterprise systems. Most large enterprise systems are engineered badly. I know, I’ve seen a lot of them. Even with a resume with years of experience on appropriate sounding systems, most developers won’t know a well engineered app from a hole in the head. Now give these guys a couple of years hacking some code together for your startup and promote them to Chief Architect. Hire an expensive consulting company to help you build your systems better, and allow Chief Architect dude to ignore their recommendations. What?

Seriously. The minute you’re successful, plan to rewrite your software from scratch. Plan to hire enterprise quality developers. Move anyone with decent business knowledge (like Chief Architect dude) into business-related roles. They’ll be much more valuable there and cause you less problems. Hire a new development manager with proven experience engineering enterprise software. Pay them market rate +30% (you’re successful, remember?). Keep your developers but explain to them that you’re no longer a startup and they’re going to have to raise their game. At the same time you’ll be putting that old codebase in maintenance mode and starting with a clean slate. This will require planning with your business—you won’t be giving them new features for a while until you can rewrite your software. Believe me, you’ll end up with much better engineered software that can respond to change faster than your existing stuff.

Don’t believe me? As a successful startup looking to become an enterprise, try the following exercises:

• Add a column to an existing database table. Make it required. How many files did you need to alter to get that field to show up on screen? How many people were required to make the change? How did you migrate old data to the new format? How did you test the change, and are you sure you didn’t break anything else? How long did it take to deploy? What about rollback?
• Run a cut-and-paste detector on your codebase. Simian works for Java, C#, C++, Ruby, HTML and other code and is a great way to scare the crap out of your dev team (assuming you’ve admitted that duplicate code is a bad thing).
• Find out your automated test coverage percentage. If you’re not yet tracking this, now would be a good time. 80% coverage on a real world project is extremely good, most projects run much below this. If an automated test isn’t testing your code, how do you know it works?