Why not to estimate time

I do not believe that software developers should estimate how long a task is going to take (at least, not without having first estimated the task's complexity and novelty). Time estimates are likely inaccurate, misleading, and therefore counter-productive. It's akin to giving someone assurances that "I can definitely throw this experimental paper aeroplane five metres in the middle of this tornado."?

Inaccurate

Generally speaking to estimate we use past experience. Even estimates based on first principles (the train is travelling at 120km/h, therefore I estimate it will arrive 600km away in 5 hours) are really based on past experience of the laws of physics staying constant1.

One problem with using past experience to estimate the duration of development tasks is that every single task is different. Software can be made once and re-used infinitely, so if we have had an identical requirement in the past that code would already exist2.

Even if the task is quite familiar, the context is changing constantly: other team members are changing the code, libraries that we depend on are changing, the environments we deploy to are changing, the team is changing, the requirements are changing, the company is changing... To paraphrase Heraclitus: "no developer makes the same Git commit twice."

Precision and accuracy are negatively correlated. "I'm going to publish this post today" is more likely to be true than "I'm going to publish this post at 09:36:27.015." Range time estimates work around this problem (eg 3-5 days) but most often aren't used in favour of the simplicity of discrete estimates (eg 4 days). When was the last time you saw Jira configured to accept ranges?

Misleading

Precision bias is that humans are more likely to consider a precise value as authoritative. People are more likely to believe that 65.2% of developers spend too much time in meetings, than that two-thirds of developers spend too much time in meetings3. Similarly an estimate that we'll hit the milestone at 14:37 on Tuesday 23rd March seems like it's involved a lot of very meticulous thought, which isn't necessarily true.

Time estimates gloss over the intrinsic complexity and thus the uncertainty involved in the task. If an estimate is for one week, is it a small change with a lot of uncertainty, or a week's worth of something utterly mundane like re-ordering YAML files? Time estimates alone give the impression of confidence.

Time estimates shift the conversation away from complexity and uncertainty and towards speed. A natural response to a long duration is "can't you go faster," with "only if you make the task simpler" as a follow-up thought. If an estimate is communicated in terms of complexity, the first question is "how can we make it simpler?"

A conversation within the team of "how long will this take" is not necessarily as informative as a conversation of "how complex is this," or "has anyone done something similar before," missing an opportunity for greater insight and knowledge-sharing.

Responsibility

There is a responsibility to do some upwards management or education to folks that need software to be delivered but perhaps don't understand the process. We are not doing these people any favours by giving estimates with the illusion of certainty. They might go and make plans based on what they think are certain timelines, and end up letting people down when reality turns out differently. They might also hold developers to these estimates, and then we get into the industry-pervasive issue of low trust between developers and stakeholders. Neither of these are desirable outcomes.

We (developers) are not helping others or ourselves by misrepresenting an uncertain and not-very-predictable endeavour as certain and predictable.

When are time estimates okay?

In ideal world everything would be done just-in-time on a pull basis ala the Toyota Production System, and so estimates and projections wouldn't matter so much. However we don't live in that world, and someone somewhere needs to make a call of "if we can't get this done by some date, then we need to make a different choice." It's therefore reasonable for folks to want to know when things might be done by, and with what degree of certainty. This should ideally be done with automated tools - Pivotal Tracker had a wonderful feature of tracking a team's velocity and then projecting dates through the estimated section of a backlog. Jira lamentably does not do this. A more advanced method would be to use Monte Carlo modelling to run hundreds of probabilistic simulations based on estimates and historic variation from those estimates, to work out which outcomes are most likely. I'm not aware of a tool that does this.

Giving time estimates as a secondary concern is, I believe, reasonable. Just make sure they are communicated with a range and a confidence rating.

You can absolutely give time estimates in your software delivery practice. Just don't be surprised when people are unhappy about them not being met, and when those people get frustrated by a lack of understanding of the process.?

1. It's commonly missed that science is a type of faith - faith that the 'laws' we observe will stay constant from one moment to the next.

2. I used to joke in conference talks that if developers can accurately predict how long something will take them, then you should fire those developers - they should have made a reusable component already instead of re-writing the same code!

3. This is a made-up statistic. The truth is that 100% of developers spend too much time in meetings.