Software estimation has got to be one of the best examples of humanity as a whole not learning from its mistakes. Time and time again we attempt to estimate how long our software is going to take and it’s always always wrong; And usually it’s wrong by a lot. But we keep doing it.
Why Estimate at All? Can you?
When time and money are finite it’s important to weigh alternatives. Usually the way this happens is we try weigh software X vs software Y in terms of what will have the highest impact per time input. But complexity determines time input. And you can’t understand the complexities of software and the variables involved because they do not become clear until you are in the middle of developing the software and uncover that complexity. At the start of a project our level of understanding about the software is the lowest it will ever be, which makes it the worst possible time to estimate.
So what do you do? How do we estimate then?
Software estimation is a lot like estimating nature:
- You can’t accurately estimate whether a volcano is going to explode unless you are estimating within a matter of weeks.
- You can’t accurately estimate the weather unless the estimate is within a matter of weeks.
- You can’t accurately estimate where a hurricane is going to landfall unless you are estimating within a week.
What’s the common theme? Complexity. Nature is a very complex thing and as such the only way to estimate is to reduce complexity. The only way to reduce complexity is to reduce the amount of time that complexity can take place. Software is like that. Software is complex. If anyone tells you that anything in software development is simple they either haven’t been bit by this or don’t understand the complexity involved.
The only way to estimate accurately is by doing one of the following:
- Provide very low confidence very coarse-grained estimates.
- Provide estimates for things with low complexity.
- Provide estimates for things that are going to happen in the next week or two.
Items 2 and 3 are really just the same thing, stated in different terms. If you attempt to granularly estimate anything farther than a couple weeks out you are lying to yourself and everyone involved in your project. Item 1 is only valuable when it helps you make a significant decision about finite resources like time and money.
It’s been my experience that item 1 estimates are too tempting and can be abused, leaving item 2 and 3 as more attractive options. Don’t plan and estimate big software. Plan and estimate small incremental software.