Live data from Hacker News

Why software projects take longer than you think: a statistical model (2019)

erikbern.com

91–100 of 133 posts

Re: Why software projects take longer than you think: a statistical model (2019)

#92
post #19
post #6

Earlier quoted context omitted.

How does the ABC example extends to repeated games?

Company (or team, or individual) A "the best" is perceived to not work hard. They are perceived to be underutilized. They miss out on so much potential revenue they don't make it to the next round. Company B is obviously incompetent, and doesn't make it to the next round. Meanwhile, company C, barely competent, is perceived to make best use of resources and remain fully utilized. They are received to work really hard…

Ah right same dynamics as departments using up all allocated funds by an end of a fiscal year.

Re: Why software projects take longer than you think: a statistical model (2019)

#93

Fits with my rule of thumb for estimation. Come up with your most pessimistic estimate that feels right, then double it.

Based on personal experience, I use the factor π. Maybe the appropriate factor varies with surrounding conditions that are hard to account for. Also, use the coarsest granularity you can get away with.

Re: Why software projects take longer than you think: a statistical model (2019)

#95
post #90

99% there is no incentive to make accurate predictions.

You never had a customer rip your head off because they took your estimate as a promise and based their own deadlines on it?

Exactly. So when a customer asks for an estimate you negotiate for the biggest buffer you can get away with, there is no incentive to make an accurate prediction.

Re: Why software projects take longer than you think: a statistical model (2019)

#97
post #16

> A reasonable model for the “blowup factor” (actual time divided by estimated time) would be something like a log-normal distribution. Interestingly, we did extensive time tracking on a multi-year in-house software project and collected data comparing the estimated completion time of tickets with their actual time. The software department was under a lot of pressure to improve their forecasting, and were somewhat de…

> ...if you want to make a commitment you can take to a customer, you can just extend the lognormal up to...

What you're proposing is effectively a fancy "padding factor", it's like on Star Trek when Scotty says they can only go at Warp-8, but really, Warp-11 is possible.

Sometimes stakeholders do behave like toddlers and get red in the face and stomp around when a "promise" is broken because "we aren't there yet." (ok, maybe not literally, but whatever the adult version of a toddler flip-out is).

But most of the time people can understand that unexpected problems come up. It's perfectly fine to make log-normal plots and think about statistics, but everyone will much happier if you explain what's going on to the stake-holders instead of just giving "black-box" estimates using confidence intervals.

Re: Why software projects take longer than you think: a statistical model (2019)

#99
post #95

Earlier quoted context omitted.

You never had a customer rip your head off because they took your estimate as a promise and based their own deadlines on it?

Exactly. So when a customer asks for an estimate you negotiate for the biggest buffer you can get away with, there is no incentive to make an accurate prediction.

Now I get your point, and agree. Plus, coming out below that estimate will make for a pleasant experience.

Re: Why software projects take longer than you think: a statistical model (2019)

#100
post #98

These comments read like from a different galaxy (for me). Here it is very clear why. Management asks: how long does it take. Engineer replies: will take X man month. Management: thats too long, lets estimate shorter.

I clearly remember estimating something with a manager at a previous job, saying it will take 2 weeks. His response was, that's too long, let's try 2 days and see what happens.
Post reply on HN