Developers are notoriously bad at estimating. So much so, that it's pretty much a running joke within our industry. We laugh at ourselves but brush aside our ineptitude with an argument of 'well, software is just hard so naturally it follows that estimation is a losing game.'
This guy is a software engineer, you can tell by his awesome estimation skills, via @rvagg pic.twitter.com/b9vvWDvs2N
— HPC Guru (@HPC_Guru) April 8, 2017
There are undeniably valid points in this argument - building something that hasn't been built before (at least not by you) and estimating how long it will take is devlishly hard (if not impossible, at times). And it is certainly not helped by the constant churn in our industry, churn that is forever driving us into the unknown. Estimating how long the latest shiny thing will take to learn is not really something you can put a number to.
But what I am focusing on here is a very specific part of the estimation process. That is, after all the discovery work has been done and we know what we are building, why is it that we are so poor at estimating tasks that we've either done before or as good as? Why is it that by some sources our estimates can be out by a factor of 2-3, or even more? And why do we get this so consistently and repeatedly wrong, even when we are so self-aware of just how bad we are?
Delusions of Success
The tendency to underestimate the time, costs and risks associated with completing some future task is known as planning fallacy. It's a simple concept: when planning future work we do not accurately recall the risks or the effort in completing similar work in the past.
In other words, we filter out all the bad stuff that happened last time and convince ourselves that everything will be okay this time round. A task that previously took an hour is bound to take less time in the future because those mitigating circumstances won't be an issue this time.
We live and breathe planning fallacy every day, from estimating how long it will take to drive to a location (sure, the traffic is bound to be light this time) to how long it will take to write a blog post (including this one). We make assumptions, we downplay the risks and estimate as if nothing can go wrong.
And that's with tasks we've completed before, repeatedly, on a daily basis.
Happy Path Thinking
Of course things go wrong with software all the time, and many of them outside of our control.
How much time have you lost in the past due to bugs in other people's software. How much time have you lost to inconsistent or poorly documented APIs. How much time have you lost to downstream or upstream delays, or learning new technologies and languages? Days, weeks, or months? Really, when it's taken you years to master Java, C# or your main language or choice?
We estimate constantly as if all these bumps on the road will not be an issue next time round - there will be no bugs in 3rd party software, there will be no delays in 3rd party components, the APIs are bound to be better, and that new productivity-enhancing framework will solve all life's problems at no cost. The list goes on and on.
Many of us are guilty of happy path thinking, even when our experience should direct us otherwise. But in software I do think there are added outside influences that skew our own cognitive biases yet further.
A Personal View
There's no scientific research or proof to this next statement, this is very much personal experience, but I would say that people who are more driven to please are probably more likely to have a cognitive bias to underestimate. I include myself in that camp.
I've had to retrain myself to stop giving optimistically biased estimates in the mistaken belief that they will (a) please whoever is asking for the estimate more and (b) will satisfy the unwritten requirement that I need to do the work as quickly as possible.
The second point is an interesting one in that it is not an explicit rule on any project I have ever worked on, but it has been there lurking in the background either as part of the team culture (e.g by putting deadlines up front before estimating) or in one's own belief that as a highy experienced, well-paid engineer it is encumbent on me to do things quickly - even more quickly than my ability allows.
This is another delusion. What really happens is we spend many extra hours behind the scenes doing everything possible to bring the work in on time at untold cost to family life and team morale. Without realising it, we are providing biased estimates to satisfy a belief system and worse still our ego. Delivering things 'quickly' makes us look good so if anything we are positively predisposed to providing unrealistic estimates.
A Pinch of Reality
So what can be done to avoid planning fallacy. Well for a start you could try some of the following:
- Ask a peer. Rather than asking yourself, ask a trusted colleague how long they think it would take you to do a task. To be clear, you are not abdicating the responsibility of estimating, but in asking a peer you are hopefully subverting any bias for planning fallacy they would apply to their own time. When thinking of others we tend to be much more realistic in terms of the effort.
- Don't estimate alone. This is a follow-on from the previous point. In today's world of agile it is only right to plan and estimate as a team, however we still put too much reliance on single person estimates. Typically the person doing the work is the one who estimates the effort. This should be avoided at all costs.
- Work with realists. Realists are a pain. They speak the inconvenient truth, the truth that no one wants to hear, the truth that shines a light on our deluded expectations, but a truth that every project needs to hear. Having a realist on your team who can clearly call-out the risks and reign-in the beliefs of any over-confident optimists is essential, no matter how difficult the truth is to hear.
- Define what 'done' means. Again this is something that is well understood in the agile world but is not universally applied. An understanding of what done means should be baked into your team. To the degree that when estimating any task we are collectively aware of every step and risk to get us to a state of 'done': coding, testing, code reviewing, refactoring, learning, investigating, etc.
- Work with ranges. Don't give a single number to a task. There is far too much risk associated with development to say that something is going to take exactly 4 hours or 3 days. Instead provide a range of numbers, including minimum, maximum and most likely. Ranges better inform the decision making process and ranges can be used to model the probability of future outcomes (using Monte Carlo simulations). I repeat, do not work with a single number.
Conclusion
Software projects are late for many reasons other than just planning fallacy. And yes, software development is hard and yes, estimating something that you've never done before is almost impossible, but there are plenty of things that we can control within most projects and plenty of tasks that we have done before, or as close as. At the very least, you should be aware of the human tendency to downplay the risks and thus the effort when completing those tasks.
For the record, I didn't quite eat my dog food on this post. My own estimate on the time it would take to write was also out - by a factor of 2-3.
Article By
Tara Simpson
CEO