by Joe Collins
“When can be launch?” It is often the first question a manager or client asks. Put another way, “How long will it take to write this software?” While trying to answer this question for the Insight project, it got me to wondering, why does the question cause so much tension and so many problems in software development? It is such a reasonable question. You wouldn’t expect there to be a problem for a ship builder to give you a launch date or for a house builder to tell you when you can have the key to your house.
To explain software development to ourselves and our managers we often turn to analogies, typically construction and engineering analogies. Whilst an analogy can be useful since it makes it easy to get an idea across quickly, all analogies are inherently flawed simply because they are analogies and not descriptions of real thing. Since much of software development is a virtual we use a lot of analogies. The preponderance of engineering analogies in software development is a problem because it gives the appearance that software development is like building a boat or a house.
And unfortunately the analogies are seductive. They seem so plausible and give the impression of control. That is unless you have seen software projects develop before. As you will have noticed a piece of software isn’t a boat and neither is it a house. Boats and houses have known features which we all agree on. I have seen a lot of boats and a lot of houses, so I pretty much know what features they should and shouldn’t have. Both boat and house builders have usually built boats and houses before. Or at the very least have seen someone else build one.
The thing about building physical stuff is that it is repetitive. Not entirely but there is a lot of similar stuff to be done to all houses. The more you repeat stuff the better you get at predicting how long it will take. I suspect that the people at Toyota know exactly how long it takes to make a car, probably to the second. Building houses or boats is often bespoke so that has to be like making software; this is a classic argument by analogy. If you talk to a builder they will admit that there is some uncertainty if you are building a house. Not everything is specified and known beforehand. So it is typical to add 15-20% to the quote for contingencies, just in case the price of bricks changes or the client wants special roof tiles. That is unless ground works are included. In that case all bets are off, until you start digging a hole you don’t know what you will find and so you can’t guess what the cost will be. Builders know this.
Making software is actually closer to digging holes than it is to building house. Not that the activities are similar it’s just that digging holes is really about the unknown, and so is software development. Programmers know this. Within the software industry it is an open secret that the best way to estimate, it to try and estimate as best you can, specifying all the tasks you can think of and how long they will take. And then times by 3. Yes x3. Add a whopping 200%. It sounds bonkers, but actually this approach works really well. How can software developers, who may have years of experience, be so bad at estimating? Well they aren’t any worse than anyone else; it is just that software development is all about the unknown, not the well-known. If there is a piece of software that does what you want you don’t get software developers to write it again, you just copy it. Copying takes no time at all and often costs you no money. You can’t do that with a house. Software development is never a repeat of something you have done before. Why repeat what you can copy at the press of a button. If you are creating new software it is implicitly something you have never done before. And loathed though they maybe to admit it, your software developers will never have done it before.
Not only is it about the unknown, it is about Rumsfelds “unknown unknowns”. You know what a house looks like, you know what a boat looks like, and you have seen them before. You know what features they have. For your unknown (as yet uncreated) piece of software you have to think very hard about the features and what needs to be included and what can be left out. The human brain cannot get this right. You cannot plan that far ahead. Most of the software development process hasn’t anything to do with typing code into computers, most of the time is spent working out what it is you are trying to do and specifying it in such a way that it can be turned into code. If you knew what the problems were and exactly how to solve them, writing software would be quick and easy, but you wouldn’t be writing software you would be wasting time. If you knew what the problems were and exactly how to solve them, you would already have a piece of software in front of you that did exactly what you wanted. So you would copy it at the touch of a button (or more likely download it off the Internet).
So how long did our software development take? About 3 times longer than planned. Despite all our experience we too got caught by our own analogies. You see having sat down and carefully specified what was required and how long it would take it is nearly impossible own up to the fact that you must multiply the estimate by an apparently arbitrary value of 3. And if the estimator can’t do it, then convincing his boss is out of the question.
So if we know how to estimate, why is software always late? We know how to estimate, we just don’t dare. Correct estimation raises too many issues. Amongst other things it requires everyone to admit that they aren’t sure what they are doing and bespoke software is ridiculously expensive. No one involved in the process gets any benefits from these admissions, but that is another story which I can bore you with at another time.