Estimations and Orders of Magnitude

Call me a cynic, but I don’t expect software estimations to be accurate. Because software is built by humans – and they take sick days, and vacations, time to help their colleagues (hopefully), have off days as well as good ones.

But I still think estimations are worth doing. Firstly, because if we don’t have some reasonable concept of how long something will take, how do we compare the effort and impact of A vs B and make any kind of rational decision?

Mainly, though, because the order of magnitude by which we are off says something about the project. We should be off by an order of magnitude smaller than the one we estimated in. I.e. when we estimate in months, we should be off by weeks. When we estimate in weeks, days.

Being off by an order of magnitude smaller allows for humanness and human error.

Being off by the same order of magnitude we estimated in suggests the project wasn’t thought through enough at the outset. It makes a case for spikes, and discussions, and architectural reviews.

Being off by an order of magnitude larger than we estimated in suggests something went truly wrong. These are the projects that drag on and on with no end in sight, and sunk costs too deep to rationally contemplate. They sap the morale of the team and destroy your reputation – internally if not externally. They are usually a sign that some bigger change is required.