99% there is no incentive to make accurate predictions.
Why software projects take longer than you think: a statistical model (2019)
91–100 of 133 posts
Re: Why software projects take longer than you think: a statistical model (2019)
#92Earlier 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…
Re: Why software projects take longer than you think: a statistical model (2019)
#93Fits with my rule of thumb for estimation. Come up with your most pessimistic estimate that feels right, then double it.
Re: Why software projects take longer than you think: a statistical model (2019)
#94Re: Why software projects take longer than you think: a statistical model (2019)
#9599% 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?
Re: Why software projects take longer than you think: a statistical model (2019)
#96Software project estimation is fractal.
Re: Why software projects take longer than you think: a statistical model (2019)
#97> 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…
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)
#98Re: Why software projects take longer than you think: a statistical model (2019)
#99Earlier 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.
Re: Why software projects take longer than you think: a statistical model (2019)
#100These 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.