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

41–50 of 133 posts

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

#41

Post by awwaiid »

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…

I think of this often, and generally call it the https://en.m.wikipedia.org/wiki/Coastline_paradox -- in addition to perceived absorbtion for stakeholders, I think the estimators too find more details the closer they look.

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

#42

Post by jbay808 »

plutonorm wrote: post #30
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.

Fortunately, this was a tech-internal meeting; management was sympathetic and pretty tech savvy and understood the takeaway, if not all the math. They had been legitimately worried that the department was not capable of holding to commitments even when they freely selected the date to commit to. And the developers themselves, to be fair, had no idea how good their estimates actually had been the whole time, because it had been viewed through the lens that a ticket that took 8 hours should have been estimated as 8 hours.

The presentation to the sales department was very different, and can be summarized as "we'll try to be clearer from now on to distinguish estimated delivery dates from committed delivery dates, and don't be surprised if they're months apart."

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

#43

Post by ser0 »

milesvp wrote: post #23
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 distributio…

The rule of thumb that I was taught for software delivery is to double it for every layer of management you have to deal with.

So if it's just you to a customer, 1 week becomes 2.

If it's you, reporting to your manager, to a customer 1 week becomes 4.

Although I generally don't apply multipliers this liberally, I do keep in mind how many stakeholders there are that can add uncertainty and friction to a project.

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

#44

Post by TheCoelacanth »

jbay808 wrote: post #42
plutonorm wrote: post #30

Earlier quoted context omitted.

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.

Fortunately, this was a tech-internal meeting; management was sympathetic and pretty tech savvy and understood the takeaway, if not all the math. They had been legitimately worried that the department was not capable of holding to commitments even when they freely selected the date to commit to. And the developers themselves, to be fair, had no idea how good their estimates actually had been the whole time, because i…

I'm not sure if I would really consider that a legitimate worry.

Software developers' expertise is in developing software, not in analyzing statistics to predict the future.

Developer estimates are one of the best data points you have to predict how long something will take, but if you think that you can just take them at face value, you are not doing your job as a manager. You need to compare them to past estimates and how those estimates panned out during development.

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

#45

Post by ineedasername »

I'm not sure this unique to software projects. It seems like any major project is subject to similar issues. Although for software projects I think the perception is that things are more malleable, so adding a requirement/feature etc is seen as less problematic than, say, deciding a new construction project should have a few extra rooms added to it.

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

#46

Post by jbay808 »

TheCoelacanth wrote: post #44
jbay808 wrote: post #42

Earlier quoted context omitted.

Fortunately, this was a tech-internal meeting; management was sympathetic and pretty tech savvy and understood the takeaway, if not all the math. They had been legitimately worried that the department was not capable of holding to commitments even when they freely selected the date to commit to. And the developers themselves, to be fair, had no idea how good their estimates actually had been the whole time, because i…

I'm not sure if I would really consider that a legitimate worry. Software developers' expertise is in developing software, not in analyzing statistics to predict the future. Developer estimates are one of the best data points you have to predict how long something will take, but if you think that you can just take them at face value, you are not doing your job as a manager. You need to compare them to past estimates…

Exactly, hence this endeavour! Where we discovered the secret map between the software developers' predictions and reality, which management worried was completely uncorrelated but it turned out to just be the lognormal distribution.

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

#47

Post by rossdavidh »

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.

I've hear it as, "the first 90% of the task takes the first 90% of the time, and the last 10% of the task takes the other 90% of the time." :)

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

#48

Post by FpUser »

romanows wrote: post #29
FpUser wrote: post #24

Earlier quoted context omitted.

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?

I made various things. Two examples to show the range - Enterprise grade business process middleware for Telcos. Software and microcontroller firmware for law enforcement. And then everything in between.

I have never really thoroughly analyzed why I am successful with the estimate and delivery. I think I'd be way more interested in it if I was late. Since I am not I do not really care. I just am and this is enough for me.

I am eternally grateful to my University (nothing to do with comp science btw) and teachers though who taught me not to blindly remember the rules but how create those. I guess this helped me to become who I am.

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

#49

Post by dchuk »

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…

If you ever port this to jira, I’d give it a shot

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

#50

Post by temporallobe »

Sometimes it comes down to poorly understood user requirements, necessitating design work in the middle of a sprint, causing a cascade of other issues like new data models, different table relationships, updates to UI screens, and on and on. Agile might pride itself on being able to handle such things, but...it’s not. Nothing is. Poor planning, no matter the methodology, results in slow, cumbersome, error-prone execution and tons of rework, 100% of the time. This was not a meant to be a rant against Agile, but in BA (Before Agile) we spent a great deal of time in requirements gathering and architecture research, so that by the time we were ready to code, we could focus on the how and not the what. And damnit, in BA we had requirements documents that actually described what needed to be done. For sone reason that is probably a misunderstood principle of Agile, requirements are considered completely unnecessary or at best a waste of time. The prevailing attitude seems to be just build the darn software, we’ll figure out the requirements later. This is like trying to build a plane while on the runway with passengers trying to board and the control tower screaming at you to take off.
Post reply on HN