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

51–60 of 133 posts

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

#51

Post by temporallobe »

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…

And management would like to add something like “optimism points” so they can cancel that out and have better metrics to report to stakeholders.

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

#52

Post by zaptheimpaler »

temporallobe wrote: post #50

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

All things considered, agile probably still produces results faster overall. Its like running the requirements gathering & software dev concurrently rather than serially.

Faster = cheaper. So the logic of economics dictates that is exactly what will happen, even if it is more stressful :/

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

#53

Post by FpUser »

balfirevic wrote: post #33
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…

> I know, I'm supposed to be modest but it is the truth. I don't think you were downvoted because you were immodest (although I'm sure it didn't help) but because your comment doesn't contribute much to the discussion. Do you have any comments on the content of the article? Do you have any estimation techniques to share? What were the deadlines based on?

Here you go. From the article:

>"People estimate the median completion time well, but not the mean."

I do not estimate either. I estimate guaranteed delivery date and what functionality will be delivered by such date.

My "special" estimation technique is probably that I do not always do things in prescribed way. I am not afraid to look outside and find ways that would bring solutions faster (sometimes by much) than the standard recipe.

Here is the example of the unconventional way I used to save someone's butt in 2 weeks when the other company (Certified consultant shop charging $300 per hour per developer) could not do it in 2.5 month https://news.ycombinator.com/item?id=21055881

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

#55

Post by 1123581321 »

An entire management layer could be removed from the average software company or consultancy if only it were possible to maintain multiple estimates for one project. Expecting one number to inform resource scheduling, account management and new business is expensive.

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

#56

Post by jdlshore »

temporallobe wrote: post #50

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

> And damnit, in BA we had requirements documents that actually described what needed to be done.

That’s some damn fine nostalgia juice you’re drinking there. Can I have some of that?

Me, I had the time and expense of requirements documents combined with the pleasure of them not actually describing what needed to be done.

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

#57

Post by chris11 »

ser0 wrote: post #43
milesvp wrote: post #23

Earlier quoted context omitted.

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.

I've noticed that increasing the number of something usually indicates increases complexity. Working with another team takes more time than just keeping the work in one team. Working with two takes longer. Same with things like the number of repos, languages, or services.

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

#58

Post by kqr »

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 is probably impossible to do with any statistical significance, because of its rarity and how contributing factors change over time. Getting in the right ballpark matters a great deal.

Verifying that you get in the right ballpark (only 1 in 20 blow their committed date, and they do so independently in time, etc, the usual value-at-risk stuff) is fortunately also trivial, no matter the underlying distribution and it's parametrisation at the time.

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

#59

Post by kqr »

edoceo wrote: post #37
milesvp wrote: post #23

Earlier quoted context omitted.

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…

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.

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

#60

Post by kqr »

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…

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

Which is a shame and causes so much wasted work. I wish we all got better at this.

Post reply on HN