The desire to make software development “cheaper” is something I hear a lot. It’s also usually a red herring. The irrelevance of “cheaper” becomes apparent when you start asking what is it exactly that they would like to be cheaper. Before long you’re dividing the cost by meaningless measures such as number of projects, features, stories, requirements.
These measures aren’t remotely comparable though. If we go further, any output metric in software that can be counted (and therefore compared) like lines of code, function points, complexity points are all useless. Here’s a great story that illustrates this well:
In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw’s region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
I’m not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.
So, clearly cost per unit of output is meaningless. Add to this the fact that as an industry we produce an awful lot of software that is never or rarely used and it’s clear that output really is the wrong thing to optimise for. If they really want to reduce the annual cost of software development, well then that is easy. For a short-term win in this game, just take last year’s budget and cut it back by whatever reduction you’d like to see. Ten percent cheaper? Done. If your current annual expenditure on software is unsustainable, then this may be the correct course of action. But let’s not pretend that you’ve made it cheaper to get the same thing.
Much of the cost incurred in software development is learning. Some estimates suggest that the learning curve for a new team can be as long as 18 months before they are at their peak of productivity. I heard a great example of this recently: to ramp up a new team to deliver a project would cost twice as much as if they were to use an existing team. One of the worst things you can do if you are concerned about cost is to wrap your software development up into a project vehicle, creating a temporary organisational structure that takes a long time to get going, and at the end of the project the learning dissipates, or worse, walks out the door.
The thing is, if you explore further the reasons behind the drive for “cheaper” you often find quite different frustrations being expressed. They start to talk about how slow it is to get anything out of I.T. and how even a small change takes months. Press a little further and “time to market” gets raised, usually with a story about a project that took much longer than thought reasonable. Ask more around this and you’ll probably hear that the end result didn’t really meet expectations in terms of the value delivered, but changing it so that it was more valuable was difficult.
What we’re starting to hear now is the real frustration. It’s not cost so much, but speed, flexibility and ultimately: value for money. Cheaper makes perfect sense if you’re talking about commodities – none of us want to pay more for something that delivers the exact same outcome. But it is a meaningless adjective when applied to product development.
The only metric that could possibly make sense is the cost per unit of value – not the output, but the outcome. What makes this hard is that value is not distributed evenly in product development. Value is rare, extreme and obvious only with the benefit of hindsight – some of the most valuable things we build will only be recognised as such after we’ve built it. We are mining for diamonds, but there is a lot of “not-diamond” in the material we carve out. Looking at cost per bucketful of material may be necessary, but it is not even remotely sufficient. A mining method that is more expensive per bucketful of material, but which has a higher probability of yielding diamonds can be a good thing. At the end of it all, it is the outcomes that matter.