http://coding.abel.nu/2012/06/programmer-time-translation-ta...
I occasionally just paste this link with no explaination at the end of emails containing time estimates.
Why are software development estimates regularly off by a factor of 2-3?
11–20 of 173 posts
Re: Why are software development estimates regularly off by a factor of 2-3?
#12The joke between us engineers at work is to estimate the project time, then multiply by pi.
Re: Why are software development estimates regularly off by a factor of 2-3?
#13I just don't know why people won't arbitrarily add 2-3 more time on the estimate...
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: Why are software development estimates regularly off by a factor of 2-3?
#14Imagine you are going on a hike to the top of a mountain. Countless paths exist between you and your destination. Most of these are dead ends. Every dead end forces you to backtrack, sometimes all the way to the beginning. Software is a lot like that.
Then whoever was planning the hike decides to go to a different peak when you're halfway up the mountain.
99% of the time you'll die before reaching the peak due to lack of water or food.
Re: Why are software development estimates regularly off by a factor of 2-3?
#15Because management looks at you funny when you say something simple will take 4 months. Then they lie and say that it couldn't possibly take that long. And the reason they lie is because there's no negative to them tying to you. Their job is to get you to go faster, and they are allowed to lie as part of their job, if it makes you go faster. The reality is that it doesn't make people go faster. It makes people leave…
While I agree with many of the other reasons and believe people in general can't estimate very well, I believe that for businesses this is indeed the fundamental reason. Even in a relatively understanding and engineering-centric environment, when I give what is probably still a bad under-estimate, I will get pressured on how we can reduce that number. I can't even imagine what it would be like in an environment that wasn't relatively understanding and engineering-centric.
If you don't want to hear the truth, you won't. Humans have known that since long before software engineering existed... or a subset of them, at least.
Re: Why are software development estimates regularly off by a factor of 2-3?
#16Egos.
Re: Why are software development estimates regularly off by a factor of 2-3?
#17Imagine you are going on a hike to the top of a mountain. Countless paths exist between you and your destination. Most of these are dead ends. Every dead end forces you to backtrack, sometimes all the way to the beginning. Software is a lot like that.
Your boss has also read about this hot new way to hike up mountains, and it is now mandated that you hike in this fashion.
Re: Why are software development estimates regularly off by a factor of 2-3?
#18So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let's extend the analogy somewhat... this isn't your first hiking trip. In fact, you've been on dozens and dozens of hiking trips. You're an experienced hiker. Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination? The reason is that if you miss your estimate, it probably won't matter. Your sherpas will be there at every stop with your food, water, and tent. You have nowhere to be any time soon, so estimating your time just isn't important enough to worry about.
Developer estimates are regularly off because they seldom impact the developer directly. Experienced development managers will pad the hell out of the developers who give them the worst estimates. Most developers will explain all the complexity of what threw their estimate off without acknowledging the huge mistake of not anticipating extra complexity in the first place.
My estimates in my early career were no better than anyone else's, ie way off -- especially for more complex projects. I'd explain what happened to my managers and soldier on. The very next task that came up, I'd give my manager some best-case estimate of how long something would take and the cycle would begin again.
That all changed once I started to do consulting for myself using "not-to-exceed" pricing. The first multi-month project I did killed me. My effective hourly rate went down to sub McDonalds levels and took much longer to deliver than I had expected. After that project, I did a post-mortem on the project to figure out where I went wrong. I came up with several spreadsheet templates and checklists to run through before giving any more estimates.
Mostly I just concerned myself with getting a hell of a lot better at estimating project duration and difficulty. Like most things, when you really pay attention to it and practice it, you get better at it.
Re: Why are software development estimates regularly off by a factor of 2-3?
#19I admit it's funny but if I showed this to a non-programmer friend, he'd be asking why I didn't research my route better or start on an unknown trail with minimal planning.
Because the research will take a significant part of the project time. Once the thorough research is done - third-party libraries are verified (that they do what's needed, and not too buggy), prototypes are written (to confirm libraries and internal dependencies work as expected), proof-of-concepts are run (to actually see that it's possible for a reasonable effort), time is measured (to confirm the way to go), interfaces are clarified (as part of the research, specifically, in the architecture department), results are estimated (basing on all results above), specifications are formalized (and agreed upon) - there is an awful lot less of what to do.
Re: Why are software development estimates regularly off by a factor of 2-3?
#20Okay, I agreed (had no other choice) with management to not have less than 20% variance in my estimates.(read: negotiated-and-reduced estimates) as a part of our performance metrics.