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

21–30 of 133 posts

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

#21

Post by godot »

In my experience from the past decade, it is often the case that, the difficult thing isn't estimating how much time the proposed project takes to build (this is the difficult part for some devs though), but it's how much other stuff comes up. Stuff includes everything not related to your project. E.g. your last project that is now on prod, where bugs were reported and need to be fixed. Another team needs your expertise on something and next thing you know you're in a 2 hour meeting with them, and also reviewing their 1000-lines PR. Maybe a real production fire is happening and you have to help and it takes you the next 2 full days on it.

Because of this, my general approach when estimating a project in my head is how much time I know it would take me if I get to work full time on it with nothing else on my plate. Then I can better estimate how much time realistically it would take after factoring in X number of hours per day on distractions. In many cases I also communicate with the stakeholders (PMs, biz ops, leads) directly "This is how long it would take me if I dedicate full work days on it" and let them take it at face value too. (It's a sentence that usually ends with "So realistically probably [2x of what I just said]")

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

#22

Post by Jtsummers »

vbtemp wrote: post #19
sorokod wrote: 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…

Did you swap B and C here? C was the “completed with a bit of extra money” one in your original where B never finished.

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

#23

Post by milesvp »

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 find this interesting. I've been told that law schools teach that when estimating how long something will take (not how many hours of effort, but calendar time) they say to double your estimate, then increase the units by one. So what you think is a 2 hour task will actually take 4 days to complete. 4 weeks will take 8 months.

I wonder how much of that is professional wisdom that embodies this lognormal distribution. Law isn't quite the same as dev, since there can be a lot of lost calendar time just due to certified mail, or court dates, or whatever. But I've found that when I apply this formula to my estimates, I'm a lot less anxious when I start to bang my head against unforeseen setbacks.

Of course, knowing which value to emphasize to a manager depends on why they want the estimate. Sometimes they really want the effort estimate, and sometimes they want the calendar estimate, and I'll sometimes give both if the context warrants it.

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

#24

Post by FpUser »

FpUser wrote: post #9

Over the course of my life I've designed and built many products/projects. Not a single one that had deadlines imposed by the customer was late. It might deviate on non critical feature set but the main course has been always served properly.

I know, I'm supposed to be modest but it is the truth. And I did not mean just me personally. Some things I did on my own and for some I had to involve team.

I think one of the reasons is that while I am reasonably good at architecture and programming in general I do not really get hung up on processes / languages / tools / technologies etc. What makes me tick is when I see the product working and serving people. That's the only thing I really interested in.

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

#25

Post by lambda_obrien »

danaliv wrote: post #17
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…

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.

Sometimes you even fall through the floor and find a whole 'nother world down there.

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

#26

Post by vbtemp »

Jtsummers wrote: post #22
vbtemp wrote: post #19

Earlier quoted context omitted.

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…

Did you swap B and C here? C was the “completed with a bit of extra money” one in your original where B never finished.

Thank you! Fixed in an edit

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

#28

Post by kvee »

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 using it on 1 project for and it's actually working surprisingly well.

We're also in the process of rolling it out to most of our other projects, or at least the ones using Pivotal Tracker, which is the only tool we're supporting right now.

If happen to be using Pivotal Tracker are interested in testing it out yourself and giving us any feedback you might have, plz shoot me a message at the email in my profile.

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

#29

Post by romanows »

FpUser wrote: post #24
FpUser wrote: post #9

Over the course of my life I've designed and built many products/projects. Not a single one that had deadlines imposed by the customer was late. It might deviate on non critical feature set but the main course has been always served properly.

I know, I'm supposed to be modest but it is the truth. And I did not mean just me personally. Some things I did on my own and for some I had to involve team. I think one of the reasons is that while I am reasonably good at architecture and programming in general I do not really get hung up on processes / languages / tools / technologies etc. What makes me tick is when I see the product working and serving people. Tha…

What kind of things do you make, how well do you know the technology/domain, what are the customers/users like, and how long out are the deadlines set? Why do you think you're so successful when so many other people have problems with estimating schedules?

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

#30

Post by plutonorm »

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 bet that analysis went down like a lead balloon. Any other response than "we were a naughty department, but we have fixed the problem and are really sorry about it" would have fallen on deaf ears at all the places I have worked. Log-normal? Most people outside of tech dept dont know the difference between mean, median and mode.
Post reply on HN