Today, *yet another article* about Software Estimates was posted on /r/programming. Again, it fails right from the starting point.

Why are software estimates wrong?

Most (all?) articles and comments about estimates seem to begin from a starting point that is already wrong. That starting point is not knowing what an estimate is. Unfortunately, it's not only the people *writing* about it. Most people asking for, giving, and receiving estimates, aren't really managing **estimates**.

The problem is this: Most people think of an estimate as a *single number*. How long will it take? About 3 weeks. How much will it cost? About 10000. Those are not estimates. At most they are *a piece* of the estimate. Sadly, both parties ignore this and so they each infer the rest from that single piece.

The correct way to manage an estimation is by acknowledging it is composed by not one but **two** figures. One is the figure given above. Say we're talking about time estimates, so “1 week”, “2 hours”, “3 months”. The second figure is actually *more important*. It's the confidence of the estimation. It's the estimation of how right or wrong the other figure can be.

And so, a *better*, more correct, way of managing estimations is to always include that confidence. You can say e.g. “I'm pretty confident this will be done in 3 weeks, plus or minus 3 days.” or “This will take at least 4 days, at most 7”. You can optionally (but I'd encourage you to do so whenever possible) include the reasons or conditions for the estimate: “…4 days, at most 7, depending on whether we find X and Y and we get Z soon enough”. Sometimes you can even include extraordinary conditions in your estimate. Things like “This generally takes a week plus or minus one day, but sometimes X happens and then it takes 3 weeks. The chance of this happening is generally low, but I don't have precise information on the status of X at this moment.”

Estimates are a compound, not a simple, single figure. And, yes, treating them as a simple, single figure looks *very* appealing; it seems to make things simpler. But there, exactly, lies the problem. Doing so you're choosing to ignore and discard the relevant part of the information. The part that later will cause your frustration and problems. “You said 3 weeks; why isn't it done yet?” Well, yes, I said three weeks, but I also said “plus or minus 1 week” and I gave you the reasons and circumstances under which it could be delayed. You **chose** to ignore that part. And most managers do because it does really simplify their processes and management.

But it is a also problem for the developers that are *giving out* estimates, of course, and most developers don't even notice they're doing it wrong. “This will take 2 days” is **not** an estimate. There is nothing in there that expresses the *approximation* intent. You need to express that intent; it cannot be implied. You need to tell the person asking just how precise -or not- the estimation is. If you don't, what you're doing is giving them a fixed deadline, and naturally they will take it as such and run with it.

But, well, if we all continue to give out estimates on the spot, simplifying them to a single figure, then they will always continue to bite us back.