Software Estimates That Dont Suck

Yeah – software estimates are mostly wrong. Developers don’t like to give estimates. They hate the moment you ask about estimates for their work. You know why? because no one really know what it takes to write a software.

WHY MOST ESTIMATES GO WRONG

We imagine smooth progress. We don’t account for bumpy roads. We think road ahead is as smooth as where it all began. The road anecdote reminded of this famous XKCD webcomic:

There are hundreds of things we don’t generally account when arriving to numbers.

We think environment setup for a developer is just a minutely job, but it took a day for John to figure our why the heck Docker networking isn’t working.

The use cases we agreed on had too many holes, it is evidently understandable the second day of discussion that business analysts did a terrific job missing important scenarios that business would want on day one. And, adding to that, project management added one more layer of pull requests approvals which was not the case when estimates were provided. And, yes - Maria had a medical emergency that put a another hole on the already drowing boat. There were numerous things that was not accounted at all.

One thing that is worth to mention at this juncture is that the understanding the cone of uncertainity. The element of uncertainity only decreases over the period of time. However, estimates tend to assume some level of certainity over it to provide a number. This, as well know, is a literal lie.

SO HOW TO GO ABOUT ESTIMATE

At Exzeo, where I spend most of my day we’ve been experimenting with various estimating techniques. The estimating nature broadly falls into two category, in my view.