If Developers Nail Estimates, They Are Lying To You

Often is seen as maturity and sign of expertise, the fact of being able to give specific and reliable estimates. But that goes against the nature of software development itself.

Photo by Fausto Marqués on Unsplash

How reliable are estimates?

The most difficult work in the software development is grasping the exact requirements. I often say that once we know exactly what we have to do, the job is done. That is because the job of the developer is translating the customer needs into computer code, but the effort is not in the translation itself, but in the definition of all possible scenarios. The computer does not tolerate ambiguity, so the developer has to spend a most of the effort thinking and solving all missing requirements.

And that is the first factor that affects the reliability of estimates. The finest is the detail in the requirements, the more reliable are the estimates. Any uncovered detail may explode in new consequences that may affect other requirements, and affect the total final required time. That is why, often, developers decompose stories in smaller tasks to get better estimates. But the effort may not be worth it.

There is also another principle: the more specific estimates are, the less reliable they are. For example, given a small task, we can give two different estimates: one hour, or less than one year. If we say one hour, it might be more accurate, but we can get wrong if it takes two, or one day. But, if we say less than one year, we will be right. So, specificity really affects.

That is the picture once we have the estimate, but we do not know the result. Yet, what can happen?

Estimate outcomes

Once the job is done, we can see three different outcomes:

1. The functionality is implemented just on time.
2. The functionality is implemented faster than predicted.
3. The functionality took more time than expected to…