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

Why software projects take longer than you think – a statistical model

erikbern.com

Post reply on HN
Print view View original

31–40 of 324 posts

Re: Why software projects take longer than you think – a statistical model

#31

Post by mattsfrey »

acd wrote: post #18

US navy has developed something similar with beta statistical distribution. You estimate "Optimistic", "Most likely" and "Pessimistic" time estimates for each task in the project and then use beta distribution on it. Some tasks take way longer than estimated. Here is the link to the time estimation described above with Beta distribution. https://www.isixsigma.com/methodology/project-management/bet...

I've seen a similar model that I've adopted for my own projections which is 30/60/90 - the 30% chance scenario which is highly successful but less likely, 60% chance scenario that is good with a relatively decent chance of success, and the 90% chance scenario that is the lowest outcome but will almost certainly happen.

Re: Why software projects take longer than you think – a statistical model

#32

Post by StreamBright »

iraldir wrote: post #4

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

It is very easy to answer. Different people have different efficiency, therefore, a task completion does not depend solely on its complexity but also on who is executing it.

You should think about it (even though there are no actual physical units you can use to make this work):

Time to deliver a task = complexity / developer efficiency

This is why it is hard to develop a method to estimate time for development tasks.

Re: Why software projects take longer than you think – a statistical model

#35

Post by taneq »

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

100% this. It's not your job to say something that will make your client happy. It's your job to tell them your honest assessment of the task.

Re: Why software projects take longer than you think – a statistical model

#37

Post by oli5679 »

In the UK, bookmakers offer 'accumulator' bets, where a punter can select many outcomes, getting a big prize if 100% correct.

This takes advantage punters' failure to accurately multiply probability - 10 events with 80% probability have joint probability Something similar happens with planning, where people fail to compound many possible delay sources accurately.

Dani Khaneman covered this in Thinking Fast and Slow, also showing that people overestimate their ability, thinking they will outperform a reference class of similar projects because they are more competent.

https://en.m.wikipedia.org/wiki/Planning_fallacy

Re: Why software projects take longer than you think – a statistical model

#38

Post by neilwilson »

hnzix wrote: post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

I've worked on twice my gut feel for years. It's generally pretty near the mark.

Humans are optimistic by nature. Even somebody as pessimistic as me.

Re: Why software projects take longer than you think – a statistical model

#39

Post by js8 »

jfoutz wrote: post #28
iraldir wrote: post #4

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

there is an uncharitable response to this thread, which is marked dead. I do think there is a kernel of truth in that response, which is nothing more than mocking. why fibonacci? I think it's reasonable to say time includes an exponential error. an estimated 1 hour task is very different than an estimated 1 week task. i see that 1 hour, 1 day and 1 week estimates are progressively, and likely exponentially, worse. Is…

The kernel of truth of that response is that you won't get more certainty about an estimate by adding more uncertainty, no matter in how much pseudo-scientific cargo-culting mumbo-jumbo you cloak it. (Unfortunately, HN readers don't really like sarcastic commentary which requires reader to think it through. Time is precious, and we just want to be coddled, give me your opinion ELI8 straight, because there is no time to think!)

Re: Why software projects take longer than you think – a statistical model

#40

Post by onion2k »

nicoburns wrote: post #25
onion2k wrote: post #12

Earlier quoted context omitted.

Sure, in the same way a bad manager will say "No, that's too high, I'm going to reduce your estimate" if you use a single number. Bad managers are a thing. Make sure you get a good one.

Yep. I still remember my first manager, who doubled every estimate I gave him. He was great.

Definitely a good manager, but Hofstadter's Law says that's still too low. :)

https://en.wikipedia.org/wiki/Hofstadter%27s_law

Post reply on HN