Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

infoq.com

Post reply on HN
Print view View original

21–30 of 49 posts

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

#21

Post by crasshopper »

x0x0 wrote: post #6

Yet another place where intuitions derived from the normal distribution about the behavior of distributions screws people. An explanation I like, from michaelochurch: Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. How long is this string of tasks going to take? Summing the median time…

If, as the article says, "Clients’ Focus on Low Price Is a Major Reason for Effort Overruns", then probably a simpler theoretical explanation can just be the winner's curse.

No need to talk about distributions, gaussian or otherwise.

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

#22

Post by crasshopper » 

   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 high at the start, but the estimate ends up being close to right surprisingly often.

This article says 30% overruns are common, which is within my former boss' +100% bounds.

The other nice thing about doubling your cost estimate is it prevents you from catching the winner's curse and landing an overly-stingy client. Plus if you really can keep costs within your spec for the project, then you win extra profits. You'll never win that "game" if you don't leave room for error.

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

#23

Post by YZF »

crasshopper wrote: post #22

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…

Doubling your estimate is a common rule of thumb that goes way back but over time if you keep learning from your previous estimates you should be able to become more accurate on average. There's another subtle thing going on is that many times when the estimate increases so does the actual time, a self fulfilling prophecy, hence Hofstadter's law...

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

#24

Post by blutoot »

Can Machine Learning (or NLP) ever help in estimating effort based on expected lines of code where the model would be trained upon similar applications/files that already exist? If so, is anyone researching this in academia or in any research lab?

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

#25

Post by crasshopper »

YZF wrote: post #23
crasshopper wrote: post #22

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…

Doubling your estimate is a common rule of thumb that goes way back but over time if you keep learning from your previous estimates you should be able to become more accurate on average. There's another subtle thing going on is that many times when the estimate increases so does the actual time, a self fulfilling prophecy, hence Hofstadter's law...

Agreed, if you're doing the same kind of work (or similar enough) over time.

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

#26

Post by ams6110 »

crasshopper wrote: post #22

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.

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

#28

Post by Cacti »

x0x0 wrote: post #6

Yet another place where intuitions derived from the normal distribution about the behavior of distributions screws people. An explanation I like, from michaelochurch: Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. How long is this string of tasks going to take? Summing the median time…

Exponential feedback is a bitch!

When I put together plans and estimates, I always take a lot of care to separate out those things which are linear and those things which exponentially impact other things within the schedule, along with the sort of inflection points. I may not know where I'm going to roll a 9 or 10, as they may crop up anywhere, but there are certainly areas where they are more possible and less possible.

In a sane world, at least. Can't do much with a black swan.

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

#29

Post by dror »

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 to run late and over budget. It's not that complicated. Spend 3-6 months defining all the details of your new web application, promise not to change anything on the fly, don't ask us to make it work on IE 7, and by the time we do 3-4 of these, we'll be able to give you a good estimate.

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

#30

Post by tunesmith »

Many customers/clients don't even want accurate estimates. Given the choice between an accurate estimate of $x, and a competing estimate of $0.75x with later surprises and deadline stress and renegotiations to pay another $0.35x for "phase 2" which gets the product up to what they originally wanted, especially when the business relationship has "bonded" in a way where it's all rah-rah, go-team, we're-in-this-together... clients will go for the latter path way more often than they should.

Part of the reason estimates are inaccurate is because there's that business disincentive to be accurate.

Post reply on HN