Estimation is difficult.
Most people aren’t good at it–even in mundane situations.
For example, when my wife asks me how much longer it will take me to fix some issue I’m working on or to head home, I almost always invariably reply “five minutes.”
I almost always honestly believe it will only take five minutes, but it never does. Most of the time my five minutes ends up being half an hour or more.
But, in comparison to the world of software development efforts, my five minutes estimation is usually fairly accurate–it’s only off by a factor of six or so.
It’s not unheard of to have software development estimations be off by as much as one-hundred-fold. I’ve literally had an hour long estimation turn into two weeks.
But, why are software development estimations usually off by so much?
Here are the four biggest reasons I have found:
Reason 1: The unknown unknowns
This phrase was first uttered by former Secretary of Defense of the United States, Donald Rumsfeld. It basically refers to those things that we don’t even know that we don’t know.
By far, this is the biggest reason why software developers often flub at giving good estimations. It also happens to be the primary reason why I suck at telling my wife how long it will take me to get home–I don’t know about the distractions that I don’t know about yet.
Software development has a lot of unknowns. Some of the unknowns we know about.
When we first start a project, we might have a good idea that we need to store the data in a database, but we don’t know how we’ll do it. That is a known unknown. We know that we don’t know something that we’ll eventually need to know.
Estimating a known unknown is pretty difficult, but we can do a decent job of it if we can compare it to something similar we’ve already done before.
I don’t know how long it will take me to write this particular blog post, but I know about how long it has taken me to write other blog posts of a similar length.
What is really scary though, are the things that we don’t even know we don’t know yet.
These unknown unknowns sneak up on us, because we don’t even know they exist–by definition they are unknowable. It’s one thing to know that we have a gap in a bridge somewhere that we have to cross, it is a whole other thing to have to cross a bridge blindfolded and only find out about gaps when you fall through them.
Constantly, in software development, we are faced with situations where we have to encounter these unknown unknowns. There is no good way to estimate around them. The best we can do in these cases is give ourselves a lot of padding and a lot of rope so that we can climb out of any gaps in the bridge that we fall into.
Reason 2: Lengthy time periods
As if unknown unknowns weren’t bad enough, the deck is stacked against us even further.
Most software development estimations involve fairly long periods of time. This has changed somewhat with Agile development practices, but we still are often asked to estimate a week or more worth of work at a time. (Plus, let’s not forget those sneaky project managers who try to throw Agile projects into Microsoft Project anyway and say “yeah, I know this is Agile and all, but I’m just trying to get a rough idea of when we’ll be done with all of the features.”)
It’s fairly easy to estimate short periods of time–well, I guess unless it’s me telling my wife how long it will take for me to get off the computer. Most of us can pretty accurately predict how long it will take us to brush our teeth, write an email or eat dinner.
Long periods of time are much more difficult to estimate accurately. Estimating how long it will take you to clean out the garage, write a book, or even just to go grocery shopping is much more challenging.
The longer the period of time you are trying to estimate, the more that small miscalculations and the effects of known unknowns can cause an initial estimate to be grossly off target.
In my experience, I’ve found that estimating anything that will take more than about two hours is where things really start to go off of the rails.
As a mental exercise, try and estimate things of varying lengths.
How long will it take you to:
- do 10 pushups?
- make a cup of coffee?
- go to the convenience store and buy something?
- write a one page letter?
- read a 300 page novel?
- get the oil changed in your car?
Notice how the things that can be done in under half an hour are very easy to estimate with a high level of confidence, but as you go out further in time it gets much more difficult.
Most of the time when we do software development estimates, we don’t try and estimate short things, like how long it will take to write a single unit test, instead we tend to estimate longer things, like how long it will take to complete a feature.
Reason 3: Overconfidence
I’m pretty presumptuous when it comes to estimations. I usually think I’m very accurate at making estimations. My wife would disagree–at least when it comes to making estimations of time things will take me. History would probably tend to vindicate her viewpoint.
As software developers, we can often become pretty convinced of our ability to accurately predict how long something will take. Often, if the programming task we are about to embark upon is one we feel confident about, we can be pretty aggressive with our estimates–sometimes to the point of absurdity.
How long will it take you to get that feature done?
Oh, that? That’s easy. I can get that done in a few hours. I’ll have it done by tomorrow morning.
Are you sure? What about testing? What if something comes up?
Don’t worry, it’s easy. Shouldn’t be a problem at all. I just need to throw a few buttons on a page and hook up the backend code.
But, what happens when you actually sit down and try to implement the feature? Well, first you find out that it wasn’t quite as easy as you thought. You forgot to consider a few of the edge cases that have to be handled.
Pretty soon you find yourself taking the entire night to just get set up in order to actually start working on the problem. Hours turn into days, days into weeks and a month later, you’ve finally got some shippable code.
Now, this might be a bit of an exaggeration, but overconfidence can be a big problem in software development–especially when it comes to estimations.
Reason 4: Under-confidence
Under-confidence isn’t actually a word. I suppose that is because someone wasn’t confident enough to put it in the dictionary.
But, just as overconfidence can cause a software developer to under-estimate how long a programming task will take, under-confidence can cause that same software developer to overestimate a completely different task, which may even be much easier.
I don’t know about you, but I often find myself in situations where I am very unsure of how long something will take. I can turn a simple task that I don’t feel comfortable doing into a huge mountain that seems almost impassible.
We tend to view things that we’ve never done before as harder than they are and things that we have done before as easier than they are–it’s just human nature.
Although it may not seem like it, under-confidence can be just as deadly to estimations though. When we are under-confident, we are more likely to add large amounts of padding to our estimates. This padding might not seem all that bad, but work has a way of filling the time allotted for it. (This is known as Parkinson’s law.)
So, even though, when we are under-confident, it might appear that we are pretty accurate with our estimations, the truth is we may be wasting time by having work that might have been done in half the time fill the entire time that was allotted for it.
(By the way, if you are looking for a good book on Agile estimation, check out Mike Cohn’s book: Agile Estimating and Planning.)
What else?
Did I leave anything out? What do you think is the biggest reason why software development estimations are so difficult?
| Reference: | 4 Biggest Reasons Why Software Developers Suck at Estimation from our JCG partner John Sonmez at the Making the Complex Simple blog. |
Good one. You have listed the facts and I’ve personally undergone each one of your points.
thanks and regards
Srinivas.K.N.
I would add the following: 1) Miscommunication or unclear requirements – recently I gave an estimate based on my understanding of the requirement only to find out later that there was a communication problem that affected my understanding of the requirements. What was once simple became much more complex… 2) Experience or skill level of implementing developer – I have learned over time to send my estimates in two formats – the generic formal one seen by all; and an informal one that reflects the skill level of the various developers on my team seen only by the team/project leader.… Read more »
It will be very gracefully if this blog could be read by our Proyect Managment here in Chile. We suffer a lot of kind like this.
I really agree with this statement, “We tend to view things that we’ve never done before as harder than they are and things that we have done before as easier than they are”. I have found this to be the case in my many years in software development. Then when we are complete we look back and think man that was a lot easier than I thought! I will check out Mike Cohn’s book, he knows his stuff!
Thanks,
Tom
In my experience the problem is not so much software developpers, but projects sponsors. i’ve been in meeting where we (tech) agreed on a given deadline, say first week of next month (week n). In comes the sponsor: no way, we need it two week before (week n-2). Yes Sir. Aye Aye Sir. Once he’s gone, you get around the table again to see what needs to be cut off in order to ship at week n-2. Then you deliver at week N-2, and then there is a new delivery, not at week N, but N+1, because there is not… Read more »
Hi John, how do you do?
How about adding a dependency with other modules like until someone closes one JIRA incident, you cannot close yours.
Thanks,
Ryoko