Live data from Hacker News

What We Do and Don't Know about Software Development Effort Estimation

infoq.com

31–40 of 49 posts

Re: What We Do and Don't Know about Software Development Effort Estimation

#31
post #29

I never understood why software estimates are so bad when other fields do so well. When a contractor gives you an estimate of how long and how much it's going to take to do a remodel, he's invariably on time and on schedule, right? And when Boeing spends billions of dollars on a new plane, they have on ready and on budget, right? So why can't software people do the same? Oh wait, complex, badly defined projects tend…

> And when Boeing spends billions of dollars on a new plane, they have on ready and on budget, right?

Well, no, they don't.

http://edition.cnn.com/2011/TRAVEL/08/07/boeing.dreamliner/

Re: What We Do and Don't Know about Software Development Effort Estimation

#32
The article says:

"A tendency toward underestimation of effort is particularly present in price-competitive situations, such as bidding rounds. In less price-competitive contexts, such as inhouse software development, there are no such tendencies - in fact, you might even see the opposite. This suggests that a main reason for effort overruns is that clients tend to focus on low price when selecting software providers - that is, the project proposals that underestimate effort are more likely to be started. "

Is that really correct? Are there studies that shows that inhouse projects (or not fixed-price projects) do not underestimate systematically as opposed to fixed-price client projects?

Re: What We Do and Don't Know about Software Development Effort Estimation

#33

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. The best advice I ever got on project-time estimation (from a biology postdoc) was: make your best, most honest best effort, and then double it. When I make projections with a spreadsheet, I have a cell that copies my grand total of all costs and call that copy "unforeseen costs". I always hate bidding that hig…

Experienced project managers multiply by pi ;)

http://alistair.cockburn.us/The+magic+of+pi+for+project+mana...

I think people should start using confidence intervals. Then the upper bounds become more realistic. If you need to estimate roughly with 90% condifence intervals, then a developer can communicate the uncertainity: I think task A will take about a week. At least 2 days. And no more than 3 months.

You can immediately see that it's probably best to either a) work with this tasks a few days and make a new estimate based on the acquired knowledge b) or if that's not possible, try to split the task to smaller subtasks to identify which parts are the most uncertain.

Re: What We Do and Don't Know about Software Development Effort Estimation

#34

An older engineer once told me a valuable tl;dr approach to engineering estimates: whatever number you arrive at, multiply it by two.

"Six to eight weeks" was the default estimate my project managers gave for anything above trivial. Long enough to make the task seem difficult, not too long to scare off the client.

Do you work at Stack Exchange?

http://meta.stackexchange.com/questions/19478/the-many-memes...

Re: What We Do and Don't Know about Software Development Effort Estimation

#35

An older engineer once told me a valuable tl;dr approach to engineering estimates: whatever number you arrive at, multiply it by two.

Double it with each layer. Double your estimate for each individual task, then when you've got the whole Gantt chart built for the iteration, double that.

Re: What We Do and Don't Know about Software Development Effort Estimation

#36
I've been giving estimates for a decade, and still feel like I'm winging it every time. Planning poker definitely works, provided you understand the requirements, and by 'understand' i don't mean you have read a spec document, but that you understand the customer's business problem and have figured out how the proposed solution aims to solve it. Sadly most large projects don't have the time in their pre-sales estimation phase for the team that produces the estimate to build an understanding of the whole problem domain. Paradoxically this low confidence in the estimate will tempt the sales team to cut it even further, since they interpret uncertainty as a liberty to seek the low bound (or even lower).

As others have pointed out in those large projects it's better not to make up-front estimates and just build as much value as possible for a fixed cost, using agile principles. However, that's typically not how large software projects are sold (or bought). Fixed price almost always means fixed scope. I'd like to know of any large software project sold to a customer in truly agile fashion (no fixed scope determined in advance). To me it sounds like a software development unicorn: you hear about it, but you're never the one building it.

Re: What We Do and Don't Know about Software Development Effort Estimation

#37
We have so much technical debt I can no longer estimate with any accuracy. Something that should take half a day takes a week. Most of the week is cleaning up all of the crap in the code, and then spend a couple hours writing the few lines of code that solve the business requirement.

Re: What We Do and Don't Know about Software Development Effort Estimation

#38
post #32

The article says: "A tendency toward underestimation of effort is particularly present in price-competitive situations, such as bidding rounds. In less price-competitive contexts, such as inhouse software development, there are no such tendencies - in fact, you might even see the opposite. This suggests that a main reason for effort overruns is that clients tend to focus on low price when selecting software providers…

There are very different inhouse environments. Some are obsessed with metrics and "improving" results.

Re: What We Do and Don't Know about Software Development Effort Estimation

#39
post #37

We have so much technical debt I can no longer estimate with any accuracy. Something that should take half a day takes a week. Most of the week is cleaning up all of the crap in the code, and then spend a couple hours writing the few lines of code that solve the business requirement.

Sound exactly how my management want things to be in a couple of years

Re: What We Do and Don't Know about Software Development Effort Estimation

#40
post #26

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. The best advice I ever got on project-time estimation (from a biology postdoc) was: make your best, most honest best effort, and then double it. When I make projections with a spreadsheet, I have a cell that copies my grand total of all costs and call that copy "unforeseen costs". I always hate bidding that hig…

The advice I got was double the number, and increase the time unit. E.g. you think the project will take 2 weeks, estimate 4 months.

Might as well estimate 8 years then, you'd probably still be right.. but is it still worth talking to you?
Post reply on HN