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 (2019)

erikbern.com

Post reply on HN
Print view View original

71–80 of 133 posts

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

#71

Post by kqr »

csours wrote: post #13

Estimates are for projects where you know what you're doing. You can estimate home construction because you've built a home before. I can estimate the happy path. I can't estimate edge and corner cases until I get closer to the edge or corner. It's not even there until I get close to it. I strongly agree with these statements from the article: >"Tasks with the most uncertainty (rather the biggest size) can often domi…

You're saying the right thing but drawing the wrong conclusion from it, I think. If you can estimate the happy path and generate some corner cases until your 95 % estimate is right 19 out of 20 times -- that's really fucking valuable to your co-workers, your customers, and your end users.

You're not asked to be prescient -- just estimate an interval that is actually statistically useful.

The 5 % worst case events that blow up and take months when you said days, those need to be handled separately, differently.

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

#72

Post by kqr »

kvee wrote: post #28

At my software agency, we were actually inspired by this post when it was on hn a couple years ago to, in a hackathon, build a simple machine learning model around it. Then, recently, we actually built our own internal tool to add "uncertainty points" to estimates for each client project we do. And the ML model predicts better and better how uncertainty uniquely affects each project we're using it in. We've been usin…

This is interesting. Have you benchmarked it against e.g. a linear regression model built on your own subjective estimations?

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

#73

Post by kqr »

lambda_obrien wrote: post #27
commandlinefan wrote: post #12

Hofstatder’s law: it always takes longer than expected, even after accounting for Hofstatder’s law.

The 80-20 rule: the last 20 percent of the work takes 80 percent of the time.

The critical thing many people miss about this rule is that it applies recursively. So of the 20 % that takes 80 % of the time, in turn 20 % takes 80 % of that time.

Go further and you get a 50-1 rule: 1 % of the work takes 50 % of the time. (Or, equivalently, 50 % of the time gets you 99 % of the way there.)

This is a strong argument for clever scope reduction.

Edit: To be clear, this is the Pareto distribution with α=1.16 -- and I don't think this applies to software implementation. The tail isn't quite that fat, in the data I've had access to. But the general idea still applies, except with less aggressive percentages!

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

#74

Post by ncallaway »

hertzrat wrote: post #8

The hardest part of this is communicating it to a client. “What do you mean it will probably take 5 weeks, but could take between 2 and 10 weeks? That’s a pretty big span. The other programmer I asked promised it would be done in 5, period. Are you sure you know what you’re doing?”

We used to try and present estimates as a range ("between 5 and 10 weeks"), but we've settled for trying to provide a single number rather than a full span.

For our time and materials estimates, we try to provide an ~85% confidence estimate, while for fixed bid projects we try to aim for a ~95% confidence estimate (and there's usually a pretty big gap between those two numbers, for the reasons pointed out in the article).

So, in this scenario, we'd probably say to the client that it'll be done in about 8 weeks (making clear that's an estimate, and not a promise). One number, rather than a range, seems a lot easier to explain to a client and if you end up low (say it takes 3 weeks), then you have a pleasantly surprised client.

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

#76

Post by niemandhier »

Weber–Fechner law states that: "that the subjective sensation is proportional to the logarithm of the stimulus intensity".

So maybe the "time estimates" actually are estimates for expected stimulus intensity.

Think about it as 'guessing the level of dread you feel when looking at the project /after/ you finish it'.

According to Fechner this should be related to the actual difficulty by a logarithmic law ( at least for humans).

These estimates of sensation are than just normal distributed, as one would expect.

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

#77

Post by kqr »

nicky0 wrote: post #75

There's a simple method for software estimates that has worded well for me in practice. Imagine how long it should take if all goes smoothly, then multiply by pi.

What does "worked well" mean? What percentile do you practically end up at when you go back and verify after completion?

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

#78

Post by nicky0 »

kqr wrote: post #77
nicky0 wrote: post #75

There's a simple method for software estimates that has worded well for me in practice. Imagine how long it should take if all goes smoothly, then multiply by pi.

What does "worked well" mean? What percentile do you practically end up at when you go back and verify after completion?

By "worked well" I mean that x3 is the "about right" factor. As software engineers we tend to be optimisitic and so when I think "it'll take about a week", that's assuming no unforseen complications. I'm afraid I haven't conducted a detailed a statisical analysis, however. The pi method is in truth just a joke between myself and a former project manager. There's nothing magic about pi exactly. I imagine each person ought really to come up with their own mental multiplier based on their own tendency to underestimate. But 3 isn't a bad starting point for iteration.

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

#79

Post by tome »

salty_biscuits wrote: post #64

So lognormal implies the total time is the product (not sum) of lots of little random tasks. Why would this be?

Thanks for asking the question. I also wondered. I can't think of any obvious reason such a model would apply to software development.

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

#80

Post by k3liutZu »

csours wrote: post #40
BigJono wrote: post #36

Earlier quoted context omitted.

What I never get about estimates is why people don't just reduce the granularity until they have some amount of accuracy they can work with. 95% of my teams have estimated using the 'story point' crap, or rarely in days (one in hours for a hot minute, that was a fucking joke I'll tell you what). In every single one of those teams eventually some stakeholder chucks a hissy fit because some feature they're emotionally…

> "What I never get about estimates is why people don't just reduce the granularity until they have some amount of accuracy they can work with." I think you've kind of answered yourself here. Software development is fractal-like. The closer you get, the more complicated. If you want to estimate smaller chunks, you have to do a lot more work. At some point it's better to just start developing than to zoom in further,…

> At some point it's better to just start developing than to zoom in further, because at that point you're basically developing anyway.

Unfortunately this is what management / PMO actually want.

To somehow magically do the development in your head during a meeting so that you can accurately estimate some loosely defined task.

Post reply on HN