For the same reason other estimates are off by a factor of 2-5, unless contractual penalties are agreed on. The cheapest contractor gets the job, and can adjust the estimates later.
Why are software development estimates regularly off by a factor of 2-3?
111–120 of 173 posts
Re: Why are software development estimates regularly off by a factor of 2-3?
#112Earlier quoted context omitted.
99% of what some people do is derivative. But if what they're doing is software, that's expressive duplication, and it's worth trying to DRY it up. I think we have different intuitions here because it sounds like you're more in a service business than specifically writing software. I agree that a lot of any service business is standardizable, because it's mainly about people and their needs; that has a lot of regular…
I think you're wrong. Perhaps you weren't around in the early 2000s when the RAD tools were all the rage. Perhaps you missed out on the colossal frameworks of the late 2000s when everything was a factory and understanding HTTP was actually a disadvantage as the whole thing would blow up if you actually tried to access the request body. We went down the road you talk of. It was horrible. Now the pendulum swings to the…
I was in fact around in the early 2000s. And the early 90s. The pendulum swings some, but back in the early days of the web, everything dynamic was hand-rolled, just like I describe.
Re: Why are software development estimates regularly off by a factor of 2-3?
#113Software-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.
You've been talking to the wrong hardware engineers, I think.
Every engineer on my team has a characteristic "fudge factor" that represents his... optimism (say, from 1.5x to 2.5x). Once I apply those fudge factors, I add another 30% slack to the total schedule. And I usually still underestimate.
The team I'm on now has been doing a very good job compared to previous ones about getting good estimates for project duration, but the ability to underestimate is nonlinear in the project size, and most of our projects recently have been pretty small chips.
On our most recent tapeout, we did a new baseline based on a new feature request and underestimated the cost of that feature addition by a factor of 2. The total schedule was pushed out about 20% as a result. I still consider this a success in predicting the project's duration: I've been on projects where we taped out six months or more after our "commit" date.
Re: Why are software development estimates regularly off by a factor of 2-3?
#114Software-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.
Its much easier to justify changes in software requirements vs changes in hardware requirements because the perceived cost of adding a few more features on your application is low. Compare that to say.. adding another register to your chip..which might add millions to the whole production process. The changes can be made while the app is live. You can not do that for hardware.
Re: Why are software development estimates regularly off by a factor of 2-3?
#115Here's another question: "Why are software feature requirement estimates regularly off and changing while in progress?"
Re: Why are software development estimates regularly off by a factor of 2-3?
#116So 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? The reason is that if you miss your estimate, it probably won't matter.
Nice try, but no.
Developers who are DIRECTLY affected from missing estimates (e.g one man shops paying out of their own pockets, people building an app while having quit work, eating ramen and maxing their credit cards etc, developers in companies who will personally pay for any delays by attrocious, unpaid overtime crunch marches, etc) underestimate the time needed to get something done just the same. Just ask Allan Odgaard (of TextMate 2 infamy).
Re: Why are software development estimates regularly off by a factor of 2-3?
#117Software-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.
Hardware engineers have more clearly defined requirements, It's also well understood by everyone that you can't just change the design halfway through production with no additional cost. Hardware engineers clients are mostly other engineers who know their shit very well. Hardware engineering is also more formalized with a larger percentage of engineers actually possessing relevant degrees with common well established means of communicating and thoroughly clear phases of development for a project.
People hiring consultants to build them software are generally non-technical. On most projects the following problems may occur:
Problems With Clients:
1) They don't konw what they really want.
2) They are bad at communicating what they really want.
3) Not enough people from the organization are brought in to weigh in on their needs / actual duties.
4) Too many people are brought in, many with conflicting interests. (bike shedding). [1]
5) Critical omissions are made regarding idiosyncrasies of their infrastructure that are never brought to light until far too late in the project.
6) people trying to change the direction of a project late into development
7) complicated/redundant policies or procedures which are incompatible or inefficient to implement using the tools the client requires you to implement them in.
Problems with Consultants / Contractors:
1) Over confident estimates
2) They are bad at estimations / unfamiliar with the tools required to do the job
3) They are bad at communication / rooting out the the real problem early
4) Unable to detect confusion/bullshitting from a client or are unwilling to investigate it.
5) PMs who make promises they are unable to keep
6) PMs who do not understand the details and make decisions without consulting those who do
7) Developers who avoid asking the client for clarification
8) spineless developers/PMs who screw themselves to avoid confrontation
9) Procrastination
[1] http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
Re: Why are software development estimates regularly off by a factor of 2-3?
#118Software-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.
Here's the thing. Software is profitable at much lower quality levels than the hardware market will tolerate. As a result, most hardware is designed through a process that could accurately be called engineering, even though most software is not. So hardware engineers get to make estimates with the benefit of having fairly reliable engineering outputs to use as estimating inputs. Further, the business side of hardware is more culturally attuned to the realities of engineering and is therefore less likely to challenge estimates coming out of mature engineering processes.
In short, on both sides of the old one-two punch, the hardware guys have got advantages.
Re: Why are software development estimates regularly off by a factor of 2-3?
#119Okay, 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.
Reduce your batch sizes to reduce uncertainty.
Re: Why are software development estimates regularly off by a factor of 2-3?
#120Earlier quoted context omitted.
This blog article is more popular than the quora post because this blog article doesn't require people to sign up to read it.
There was a trick posted recently to HN for reading Quora articles without signing up: Tell HN: Add ?share=1 to Quora URLs to display content without login https://news.ycombinator.com/item?id=6300856
I still don't want to support any site that uses this business model. You want me to use your site? Make it easy for me to come by for the information I need.