When you make a bridge you have a plan. You know exactly how much you have to dig and how much concrete and iron you’ll use. You can ask a contractor how much and how long. Such projects do slip out of budget and schedule, but this is usually because of bad project management (and because of the inherently bad practice of RFPs). A good contractor will usually not slip much.
Because of the study that has preceded construction, you have very good understanding of what it is that you are going to build.
If the bridge was software, all you’d know before you started to build it is some vague requirements like “it must have a capacity of 7 thousand vehicles per hour in each direction”. A contractor wouldn’t be able to give you a quote.
Can we make time and money estimates if we don’t have clear understanding of what it is that we’re going to build? It turns out it’s not impossible.
Here is one of the things software teams do: We write down the list of features we need to develop. Based on our experience, we assign a degree of effort needed to develop the feature. If feature A has five degrees of effort and feature B has ten, it means we think B needs twice as many resources to develop as A.
So far we aren’t doing anything much differently than other people. The key difference, the core of this idea, is that the degree of effort is an arbitrary unit of measurement. It doesn’t mean anything. It doesn’t translate to hours or days or man-months or euros. We have special terminology for it: we call it a “story point”.
After work on a project begins, e.g. after a month, we look at the features we have developed and how many story points these correspond to. We have now measured the speed of the team, in story points per month. And we can make a realistic estimate about what it will take to build the rest of the project.
This thing alone won’t achieve anything. If it isn’t combined with other good development practices, the team speed will be high at first and very slow later. But the example serves to shed some light into how to shape the terms of co-operation between client and programmer. Traditional requirements-based and time-based contracts will give you headaches, but we can improve on those if we replace some of our wishful thinking with self-observation.