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

121–130 of 133 posts

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

#121

Post by edoceo »

kqr wrote: post #119
jbay808 wrote: post #114

Earlier quoted context omitted.

I think we're talking past each other. I'm not referring to a percentage of time being consumed by meetings and such; I'm referring to how frequently I'm asked to multitask because several urgent projects are going on at once. New priorities are added unpredictability, and sometimes I'm asked to clear all other work off my plate to fight some fire. Of course that's a sign of trouble, but it's natural for the stage th…

Maybe I fail to see the point of even bothering to estimate something that is so unimportant it can be (or even appears likely to be?) down-prio'd in favour of more important things so quickly. Could you explain in what stage to switch between things so quickly few things are ever finished, and why it makes sense to estimate those things at all, in that context?

Early stage, need effort-budget to CBA vs risk to build calendar estimate.

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

#122

Post by jbay808 »

Izkata wrote: post #118
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…

> 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 despairing that their estimates were off by a factor of about 1.6 on average Hum, 1.6x average is actually extra interesting to me - i…

This company handled time tracking quite differently than most, because everyone was paid by the hour, even devs. The same time tracking system was used to track time spent on tickets as was used to by the accounting department to track hours. If you went to a meeting you'd update your timesheet with the meeting and its billing code. People were quite religious about maintaining an accurate timesheet as part of the culture. I think it's about the highest quality dataset you could hope for.

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

#123

Post by nicky0 »

kqr wrote: post #120
nicky0 wrote: post #78

Earlier quoted context omitted.

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 o…

I guess I'm asking what "about right" means. Does it mean you finish faster than that number 50 % of the time? 90 % of the time? No statistics necessary, just your gut feel.

Ah, good question. First instinct says 'success' should be statistically 50% each way. Right in the middle of the bell curve.

But on second thought, being behind estimate half the time would be pretty sucky. So I'd like to bring the peak of the curve onto the early side of the line.

I guess ultimately it depends on the question being asked of the estimator & the implied confidence interval.

What do you think?

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

#124

Post by crispyambulance »

kqr wrote: post #105
crispyambulance wrote: post #97

Earlier quoted context omitted.

> ...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." (…

I disagree somewhat. There's a world of difference between saying "here's when we think it'll be done, but sometimes shit happens and there'll be a delay" and saying "we're 95 % confident it will be done by this date" -- especially when you have a solid track record behind the second. The first one tells you effectively nothing. The second one you can build strategy on.

> "here's when we think it'll be done, but sometimes shit happens and there'll be a delay"

I agree that a statement like that would not be useful. What I am saying is that it's better to make a good effort at estimation but then keep the stake-holders informed about what is going on, about the challenges and the mid-project delays.

Any "95%" confidence calculation is kinda dubious. It would only work if you have meticulous and accurate records, have a long-enough history of delivering the same kind of product with the same team, the same customer-base, and the same tooling, oh yeah, and everyone has the psychological safety factor to be honest. If you work in a place where that exists, more power to you, but I think that's rare.

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

#125

Post by GuB-42 »

tempodox wrote: post #96
KingOfCoders wrote: post #69

Software project estimation is fractal.

And quite possibly NP-complete.

More like NP-hard.

I don't think that something like a SAT solver will help you much with your estimations.

But you can probably turn a NP-complete problem in terms of software project estimation. The traveling salesman problem looks like a good candidate here.

Edit: come to think of it, it is like the halting problem, your project may never finish

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

#126

Post by csours »

kqr wrote: post #71
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 tha…

Sure, I think different people use estimates for different reasons.

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

#127

Post by snickerer »

A story from a rainy summer in Berlin:

One day my manager came to my office and said: 'Look at this task. How long will it take?'

I thought 'two days' and I told him 'ten days'. He said 'Ok, do it!' and went away.

I was happy that I had the chance to do it very well. To take the time to write really well structured code without pressure. And I did it.

At day 5 I my work was finished. I was proud of it.

At day 6 I took the time to re-read everything and to do intense testing. I found a minor bug and fixed it.

At day 7 I practised for my next martial arts exam during the work time.

At day 8 I went to my manager and told him 'It is finished and it is good'. He was very pleased to hear that I finished early! Before the deadline!

My colleagues were happy with the well working code.

I call this a win-win-win situation. Oh, what great memories. The day when I told my manager that the task will take 10 days.

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

#128

Post by kansface »

GuB-42 wrote: post #125
tempodox wrote: post #96

Earlier quoted context omitted.

And quite possibly NP-complete.

More like NP-hard. I don't think that something like a SAT solver will help you much with your estimations. But you can probably turn a NP-complete problem in terms of software project estimation. The traveling salesman problem looks like a good candidate here. Edit: come to think of it, it is like the halting problem, your project may never finish

> Edit: come to think of it, it is like the halting problem, your project may never finish

Uncertainty in the solution can only be reduced to the extent you have actually solved the problem. Of course, the problem may may not be solvable or alternatively, the cost can be too high.

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

#129

Post by kqr »

crispyambulance wrote: post #124
kqr wrote: post #105

Earlier quoted context omitted.

I disagree somewhat. There's a world of difference between saying "here's when we think it'll be done, but sometimes shit happens and there'll be a delay" and saying "we're 95 % confident it will be done by this date" -- especially when you have a solid track record behind the second. The first one tells you effectively nothing. The second one you can build strategy on.

> "here's when we think it'll be done, but sometimes shit happens and there'll be a delay" I agree that a statement like that would not be useful. What I am saying is that it's better to make a good effort at estimation but then keep the stake-holders informed about what is going on, about the challenges and the mid-project delays. Any "95%" confidence calculation is kinda dubious. It would only work if you have meti…

I think I can work out a 95 % estimation I am willing to stake money on even without the things you mention. It does take good management/culture, but if I don't even have that, I'm headed for the dumpster anyway and should go home and rethink the whole thing first.

> What I am saying is that it's better to make a good effort at estimation

But what does that estimation mean? If we don't know after the fact whether the estimation was good or bad, then it's useless because it's an answer to an unknown question, and every stakeholder will interpret it differently. In order to know after the fact, we must know ahead of time whether we're aiming for 50 %, 90 %, or something else.

Post reply on HN