Jason Calcanis has an excellent post on the trade offs between features and scalability, an area that can create no end of trouble in the relationship between CEO and CTO.  It’s also a story about over engineering, but Jason was polite enough not to blame the CTO for that (perhaps because the CEO is often just as guilty of under engineering!). 

Managing these trade offs is very hard to do.  Scalability can turn into kind of a maintenance programming chore, but there is no question that having to engineer scalability under fire is extremely painful.  See my article about how you’ve probably already had a Multicore Crisis for more.  Nobody wants to live through a crisis like those described.  If the crisis is bad enough it often results in either a big set back for the business, having to replace key executive like the CEO or CTO, or both.

There are a lot of approaches for dealing with the balance of new features versus scalability or other maintenance-related tasks.  I’ve always found that the best answer is finding ways to do more.  It sounds trite, but everyone wants to hear that they can have it all.  Often that means figuring out how to do more with less.  Where software is concerned, that means planning ahead.  Writing software is a bit like sailboat racing: it is costly to change directions, so you need to be on the right tack to begin with.  CEO’s have a lot of knobs and levers they can use to create change for their companies.  As we look at the alternatives, Marketing, Sales, and Product, we find that Product often has the slowest cycle time from conception to delivery.  We need to use the other two to provide some air cover for that change to happen in.

A huge time waster for software is last minute change.  Mechanisms for scalability need not be all that hard or expensive to implement if just a little time can be taken to plan ahead.  There are always obvious bottlenecks that result from having made the wrong assumptions too early.  Having to rearchitect those under fire is a recipe for disaster.  Don’t paint yourself into an architectural corner where scaling is concerned, says Dan Cresswell.  I’ve worked at three companies now that built products around Grid Architectures, and I’m here to tell you it wasn’t that much harder to do, it gave us a huge advantage, and we never could have done it if we hadn’t thought about it carefully up front.

Another issue is the wastefulness of most software development.  As I’ve mentioned in another post, 70% of the software you write is wasted.  Shocking, but true.  Consider ways to reduce that wastage.  My article mentions the use of more efficient languages and Open Source as two potentials.  You have to work hard to focus your team’s energies on things that create true proprietary advantage.  Everything else you deliver should be no better than average: it just doesn’t matter enough if you make it better.  Having a CTO that knows how not to over engineer the average stuff is a huge advantage.  Having a CEO and Product Management staff that knows not to even ask for much that doesn’t make a real difference is even better.  There is nothing worse than a diligent Product Manager who has surveyed customers and competition in exhaustive detail and delivers a Product Requirement for a feature that does every possible thing anybody could ever want but that won’t make a bit of difference in the end of the day to your company’s proprietary advantage.  If your marketing and salespeople can’t write press releases about it or include the features in sales demos, why build them unless they’re absolutely essential for your product to work at all?