Live data from Hacker News

Why are software development estimates regularly off by a factor of 2-3?

michaelrwolfe.com

131–140 of 173 posts

Re: Why are software development estimates regularly off by a factor of 2-3?

#131
post #34

I love this post; it conveys the feel of the experience so well. One of my big aha moments about estimation was a bit in McConnell's Rapid Development . He pointed out that most estimates get made with executives pressuring for short numbers. When you iterate a few times with that, you end up with the smallest number that developers can't absolutely prove is impossible. If you draw out a bell curve of probable comple…

I once read an argument that went something like this: if you're actually going to go to the trouble to build something, its expected return to the business should be so large that how long it takes (within reason) shouldn't matter. Conversely, if a project is only economic to undertake if it can be done within a certain amount of time, it shouldn't be done at all. I find that I often don't have a good feel for how l…

Agreed. Certainly, estimates of cost shouldn't be more precise than estimates of value, because ROI is the number that matters. And business is a black enough art that estimates of value are very rarely more precise than a factor of 4x.

What I think people try to get from estimates is a sense of control. But I think there are better ways of giving people not just a sense of control, but actual control.

Re: Why are software development estimates regularly off by a factor of 2-3?

#132

Because no one wants to admit they still have to learn more about the system they are going to build.

There's something to this, no doubt. I recently took part in a project where a firm was contracted due to their "expertise", which they fulfilled by hiring a team of contractors, most of whom were woefully unprepared, in terms of knowing the system on which they worked.

Re: Why are software development estimates regularly off by a factor of 2-3?

#133
post #34

I love this post; it conveys the feel of the experience so well. One of my big aha moments about estimation was a bit in McConnell's Rapid Development . He pointed out that most estimates get made with executives pressuring for short numbers. When you iterate a few times with that, you end up with the smallest number that developers can't absolutely prove is impossible. If you draw out a bell curve of probable comple…

I once read an argument that went something like this: if you're actually going to go to the trouble to build something, its expected return to the business should be so large that how long it takes (within reason) shouldn't matter. Conversely, if a project is only economic to undertake if it can be done within a certain amount of time, it shouldn't be done at all. I find that I often don't have a good feel for how l…

This of course does beg the question as to how you know when you're 1/4 of the way though the project!

Re: Why are software development estimates regularly off by a factor of 2-3?

#134
post #39
post #23

Earlier quoted context omitted.

"Developer estimates are regularly off because they seldom impact the developer directly." I think I most disagree with this. Developers, in my experience, are quite often asked to leave the company after such estimates. It's good to have a template - it helps not to forget things - but it is inherent in the work to have unknowns. Large unknowns. A good consultant would probably refuse to work on a project which woul…

Developers, in my experience, are quite often asked to leave the company after such estimates. I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.

well maybe it doesnt happen at a "developer" level, if that's what the management hierarchy calls it. But it definitely does happen on an engineering manager level and is actually fairly common in the VP Engineering role.

Re: Why are software development estimates regularly off by a factor of 2-3?

#135
post #3

Kept waiting for the punchline where the friend has moved to Las Vegas and a total replan is required.

That or the part where when he first calls his friend and says "We will be there in 10 days" and his friend says "10 days! really? I was expecting you here in 5 days"

Re: Why are software development estimates regularly off by a factor of 2-3?

#136
That's a very interesting sort of analogy. Among most of the discussed issues,

a) For one, giving enough time to come up with a project estimate is often rare. Usually people try to ask for those upfront.

b) Usually we try to add a general buffer for any unseen issues. However, the deeper you go and list tasks against time, the closer to realistic is the total.

c) Often it is just a customer giving a requirement needed at date x, or a management guy setting goal for a date y. When all you can do is to cut features but have to deliver by a given date.

d) No matter what we say, but at the back of our minds, we are not enough prepared to defend a timeline when giving it in the first place. Implementing feature x needs a week? gosh boss would say it should take a day. Latter it turns out the assumption was based upon a library which for just internal implementation reason (that you only discover upon learning it enough through actual code) is completely useless and it should actually be planned for 3 weeks at least.

Re: Why are software development estimates regularly off by a factor of 2-3?

#137

Software-development estimates are regularly off by a large margin for two reasons. First, the problem is inherently hard. Second, social and business pressures bias the estimates downward. Why is the problem inherently hard? To see why, let's imagine that the All-Knowing Fairy Godmother of Software Estimation descends from the heavens and lends to us her magic estimating function F that, applied to any software proj…

For what it's worth, I haven't seen hardware engineers complaining about this issue as much as software engineers, which I find baffling. I think if you're going to justify why software development is such a "hard" problem, you should mention what makes it so different from other fields.

In hardware design, there is more up-front time making prototypes and running simulations, so that engineers have clearer ideas about what they will build and how they will solve problems.

We don't do the same with software, though I would argue that we should.

Based on my experience, the more time you spend coming up with application prototypes that closley resemble final products, more accurate estimates you will get from engineers.

Re: Why are software development estimates regularly off by a factor of 2-3?

#138

Software-development estimates are regularly off by a large margin for two reasons. First, the problem is inherently hard. Second, social and business pressures bias the estimates downward. Why is the problem inherently hard? To see why, let's imagine that the All-Knowing Fairy Godmother of Software Estimation descends from the heavens and lends to us her magic estimating function F that, applied to any software proj…

I don't think the problem is just top-down (though I agree with all of your factors identified above). On a few occasions managing projects, I've gotten an estimate and said 'OK, I'm going to assume it ends up taking us twice as long due to stuff we haven't discovered yet...' only to have this regarded as a personal insult.

Re: Why are software development estimates regularly off by a factor of 2-3?

#139
post #18

So 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? T…

> So 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?…

100% agree on that. I did a lot of bad estimates and was directly affected by them (fixed rate projects that ended up driving my rate to "below mcdonalds worker" and some even with "lateness discounts" because I just wanted to keep the customer happy), and it took me a lot of time to get better at estimating even if I was paying from my own pocket for all the bad estimates.

Now if I am to hire a developer I will never think that "his estimates are bad because he's not directly affected by missing them"!

Post reply on HN