Why software estimation is like measuring the coastline of Britain
Developing software is several things:
- an engineering discipline, finding solutions to problems within known constraints;
- a craft, requiring skills, attention to detail, experience and understanding of industry best practice;
- an art, requiring creativity to find solutions that are feasible, elegant, efficient, and not too time-consuming to implement
Although the effort required for the engineering and craft parts of software development can be fairly easily estimated in advance - through experience of carrying out those tasks in the past - unfortunately, the creative element makes estimation hard. On a good day a developer might suddenly see an elegant solution to a tricky problem; on a bad day, chasing down a single bug can take all day with no progress to show for it.
Mandelbrot, the famous mathematician, once wrote a paper about the “coastline paradox” which shows that the length of a coastline depends on the scale at which you measure it - or for our purposes, estimate it. For example, if you only had a high-scale map of the world, and you wanted to estimate the length of the coastline of mainland Britain, you might say that Britain is about a thousand miles north to south, a hundred miles across the top and three hundred along the south coast - an estimate of 2,400 miles. But if you have a detailed map showing all the ins and outs, the Wash and the Humber and all the crinkly bits on the coast of Scotland, you'd end up with a more accurate - and larger - number. And if you sent out surveyors with proper equipment you'd get a larger number again. Britain's Ordnance Survey have done this and they say the coastline is actually 11,073 miles - nearly five times our original estimate.
If a software project takes even two times as long as the original estimate, it would be a huge problem for both supplier and customer. (So it's lucky that some parts of the process are relatively easy to estimate.) However, the same paradox applies because the only complete definition of what programs must do is the program code itself! Until the whole thing is coded up, the definition of what it should do is incomplete, and an estimate is all we have. Software developers writing every part of the program is the equivalent of surveyors visiting every part of the coast. Until that's done, we must use an estimate which we know is inaccurate - the only thing that's certain is that it will be longer than the estimate which looks at a simplified version of the problem. The customer's statement of what the software needs to do is exactly that - a highly simplified version.
Our CEO has enjoyed giving this map-related analogy to SpiffyMap's customers for some years. If you found it enlightening please feel free to share it: