Why are software development estimates regularly off by a factor of 2-3? • Hacker News Board

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

#171

Post by sixothree » Sat, Nov 30, 2013, 10:12 PM UTC

wfunction wrote: post #109

tmoertel wrote: post #64

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.

And how often do hardware engineers have to deal with business logic and workflows.

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

#172

Post by analog31 » Sat, Nov 30, 2013, 10:31 PM UTC

finnw wrote: post #156

analog31 wrote: post #121

Earlier quoted context omitted.

I've seen the opposite, where the effort and bureaucracy to change the software is so prohibitive that changes are made to electronics or even mechanics to avoid a software change.

> ... to avoid a software change. "It's OK, it doesn't need any code changes, just a modification to the configuration files, so the approval process does not apply." That company's developers just need to learn the trick of making the configuration file format Turing-complete. If you don't have time to write your own interpreter, XSLT is an easy one to sneak by PHBs. I've seen one system where 70-80% of the function…

Beautiful, Greenspun's Tenth Rule comes to the hardware department!

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

#173

Post by sechastain » Sun, Dec 01, 2013, 1:50 AM UTC

The short answer is optimism and poor assumptions. The hiking analogy works well to illustrate this answer.

Everyone who has been a part of a software project knows about poor assumptions. From the start, you don't have well-defined requirements. You don't have a complete design. You don't understand the consequences of decisions you have made or will make. Any estimate is doomed to fail in the face of all these poor assumptions.

Staggering a software project into smaller chunks goes a long way to controlling these poor assumptions and the impact to schedule and, more importantly, customer expectations.

The principles of the agile manifesto go a long way for mitigating the too common pie-in-the-sky wishful thinking that dominates software engineering. They work even better when the customer realizes they are a part of the system under development and its success - if they can keep that balanced with giving the development team the space to do what it is they do.