Business Class or Economy?

On a recent project, I misjudged the customer’s non-functional requirements: a more polished result turned out to be more important than time to market, so we had to add an extra round of enhancements before the first release. I now realise what I forgot to ask - do you want expensive software?"

I started thinking about this recently when Keith Harrison-Broninski gave an excellent talk at JavaPolis 2006. He made the point that programmers tend to be very cost-conscious, looking for faster techniques and frameworks that result in less code. In this effort to increase engineering efficiency, he explained, programmers easily miss the situations when price is less important than producing software that meets people’s needs. This is why business people are less cost-conscious. After all, he went on, 'business people travel business class'.

Business class flights are a good comparison, because I suspect that many programmers do not understand the value of a flight that may cost the same as an economy flight plus the cost of the latest development workstation. Aside from the question of whether business class flights are good value, business class passengers get significant benefits from flexible tickets, quiet and comfortable airport lounges to work and network in, and the opportunity to arrive somewhere still presentable enough to go straight to a meeting. Programmers, meanwhile, just want more tangible things like twice as much memory in their PCs, twice as many pixels on-screen and twice as much desk space.

This is why I suspect that business people usually want what a programmer would see as 'expensive software'. In web application terms, this means implementing things like:

These are things that you will not retrofit later on, because the economics will be wrong - it will seem like too big a job.

Not all software needs to be expensive: sometimes cheaper and sooner really is better, although these may only be the times when you are really building a prototype. What matters is whether you continue using the software in the future, which is how prototypes become production systems. In other words, sometimes your 'prototype' is not really a prototype at all, you should design it as the first iteration of a production system, rather than treated as a temporary solution. Lifetime is relevant because 'People remember the quality long after they’ve forgotten the price. Unless you try to rip them off.' (gapingvoid).

The immediate consequence of more expensive software is that it takes longer to implement features, or that you build fewer of them. Feature simplicity is getting plenty of press these days, with 37Signals recommending that you Build Less and execute on the basics beautifully as Apple have done with the iPod, to successfully compete with the feature-rich competition.

The commercial appeal of these successful examples is that they de-commoditise established functionality by attributing added value to design innovation and better execution, instead of the feature set, which means more profitable market differentiation. The catch is that you cannot actually ask your customer whether they want expensive software, air-travel analogies notwithstanding, because they will have no idea what you mean. In the absence of a sensible way of asking, you will have to rely on having a feel for how price-conscious your customer really is, so that you know how 'expensive' each feature will have to be in order to be good enough.

In the end, if your design is good enough to show how expensive software could be better, and your implementation has polish, then you should pay more attention to software’s non-functional requirements.

Photo: Matt @ PEK