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

61–70 of 133 posts

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

#61

Post by FooBarWidget »

BigJono wrote: post #36
danaliv wrote: post #17

Earlier quoted context omitted.

Totally. Software estimates are like looking at a dungeon map where you can see the beginning and the end, but the rest of the page is blank until you've actually entered that part of the map.

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…

In my experience, people don't estimate granularly because they want to be fast. They see this activity as a chore, an overhead, and want to get it over with quickly. And planning sessions do take a lot of time even if we minimize the time it takes to come up with estimates.

Sometimes, inaccurate estimates come back to bite us. So I regularly make the point that spending time on this chore is a necessary evil.

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

#62

Post by jbay808 »

kqr wrote: post #59
edoceo wrote: post #37

Earlier quoted context omitted.

This points to another issue I've observed is that managers/operators ask for an effort-estimate and then map that directly to calendar estimate. That and thinking that two 4h efforts can be completed in one 8h workday. MFer interrupt work so frequently how do they forget it happens? Forgot you had me in that BS 2h sales meeting "for show"!?

Yeah, but who do you think are in the best position to know what your calendar will look like? You. Always give calendar estimates. That is, after all, what matters to coworkers, to the business, to partners, to the customer, and to users.

That depends on whether you're in a position to set priorities. I can tell you that something will take a week, but I can't tell you that it will be done next week unless I'm permitted to work exclusively on it this week.

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

#63

Post by jbay808 »

kqr wrote: post #58
jbay808 wrote: 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…

I can independently attest all of your comment from my own internal research. Well summarised. I also think fitting the exact distribution is unimportant and uninteresting. The important thing is that you have roughly the right distribution and that it has the fat-tailed property of only slowly converging to normal. Why the distribution doesn't matter beyond that is that, I think, finding the exact 95 % upper bound i…

Thanks, and I'm glad to hear you've found the same thing! So including the article, that makes at least three of us, it seems.

I agree that it might not be terribly important practically, but I think it's interesting because it might hint something about the underlying nature of task planning. Sort of like how if you were measuring radioactive decay times and found a Poisson distribution, you might learn something about the underlying nature of radioactivity.

What it is exactly, I'm still not sure, but I do think there's something there to poke at.

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

#65

Post by kqr »

jbay808 wrote: post #62
kqr wrote: post #59

Earlier quoted context omitted.

Yeah, but who do you think are in the best position to know what your calendar will look like? You. Always give calendar estimates. That is, after all, what matters to coworkers, to the business, to partners, to the customer, and to users.

That depends on whether you're in a position to set priorities. I can tell you that something will take a week, but I can't tell you that it will be done next week unless I'm permitted to work exclusively on it this week.

Nobody is ever able to work exclusively on a thing for stretches of a week.

I'd suggest starting to keep track of how much of your time you can take to work on the thing you work on. If it's between 30 % and 90 %, include that factor in your estimation procedure.

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

#67

Post by kqr »

jbay808 wrote: post #63
kqr wrote: post #58

Earlier quoted context omitted.

I can independently attest all of your comment from my own internal research. Well summarised. I also think fitting the exact distribution is unimportant and uninteresting. The important thing is that you have roughly the right distribution and that it has the fat-tailed property of only slowly converging to normal. Why the distribution doesn't matter beyond that is that, I think, finding the exact 95 % upper bound i…

Thanks, and I'm glad to hear you've found the same thing! So including the article, that makes at least three of us, it seems. I agree that it might not be terribly important practically, but I think it's interesting because it might hint something about the underlying nature of task planning. Sort of like how if you were measuring radioactive decay times and found a Poisson distribution, you might learn something ab…

One thing that makes software special and might contain a kernel of an explanation is that software is scale-free: big software is build from many small software, which in turn are build from even smaller software. This makes it different from e.g. houses, which are not built from many miniature houses.

I speculate this self-similar nature drives a lot of the other odd properties we observe in software development, but I haven't come up with a specific model yet.

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

#68

Post by xupybd »

hotz wrote: post #66

I always treat it as a thumbsuck because who really knows. I could tell you two to three hours to solve it and then it takes me five minutes. I could say a week and only end up using a day.

I've always found business expectations are to complete in less time than my estimates. My estimates are often a little under as well.
Post reply on HN