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

erikbern.com

Post reply on HN
Print view View original

71–80 of 324 posts

Re: Why software projects take longer than you think – a statistical model

#71

Post by jfoutz »

js8 wrote: post #54
tumetab1 wrote: post #45

Earlier quoted context omitted.

The reason the Fibonacci sequence is used is because we don't think in an incremental scale but in a logarithm scale. In other words, we think that some simple takes 1 day, a more complex takes 3 and a even more complex takes 5 days. Usually we don't jump from 1 to 2 days when thinking about a task effort.

You could have also used approximately logarithmic scale that everybody is familiar with, namely, cash! You know, 1,2,5,10,20,50,100,200,500.. But no, here we are doing science, that's why we use Fibonacci, hey even plants and rabbits are using it.

I kinda want to grab you by the lapels and re-enact that part from Clear and Present Danger. It doesn't matter what's true, it matters what i can prove!

Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management.

In the absence of evidence to the contrary, i think i'm ready to take a side close to yours. It's useful to expand error bars exponentially as you move away from the time of the estimate, but there's nothing special about fibonacci.

Re: Why software projects take longer than you think – a statistical model

#73

Post by moccachino »

chii wrote: post #48
taneq wrote: post #35

Earlier quoted context omitted.

100% this. It's not your job to say something that will make your client happy. It's your job to tell them your honest assessment of the task.

Imagine a tradie saying it'd take 1week to finish remodelling your kitchen, and then it turns out they couldn't. As a professional, it's your responsibility to educate the client on the issue - most technical problem could be explained to a layman if the context is set up properly. The problem occurs when the client doesn't want to hear it.

From around here that's everyone's experience of tradespeople in every non-emergency task.

"Sure I can do this in 3 weeks."

Then shows up once every two weeks and finishes around the four month mark.

Re: Why software projects take longer than you think – a statistical model

#74

Post by tonyedgecombe »

teddyh wrote: post #60

According to Joel Spolsky¹, programmers are generally bad at estimating, but they are consistently bad, with the exact factor depending on the individual. So by measuring each person’s estimate and comparing it to the actual time takes after the fact, you can determine each person’s estimation factor, and then when they estimate again, you can get a pretty reliable figure. 1. https://www.joelonsoftware.com/2007/10/26…

You know that article was written to sell a feature in their bug tracker. I like Joel's writing but I'd take that piece with a pinch of salt.

Re: Why software projects take longer than you think – a statistical model

#75

Post by andy_ppp »

andybak wrote: post #15

I once had a really convoluted metaphor for estimation which involved opening boxes that sometimes contained other boxes which sometimes contained other boxes... I wonder how that models mathematically.

The problem with this analogy is that the boxes do not obey the laws of physics and fit inside eachother...

Re: Why software projects take longer than you think – a statistical model

#76

Post by pvorb »

moring wrote: post #66
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

On the other hand, you can only argue about the estimate if there is even a channel to argue about it. I have seen several cases of (1) people being told about a deadline through various proxies, so there was no point in time where they could even question the imposed deadline, (2) people not being told about the deadline at all until it was missed, so they could not argue against it, (3) people not being told about…

At least this saved the engineers quite some amount of time.

Re: Why software projects take longer than you think – a statistical model

#77

Post by GlennS »

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

Well, this is some good advice.

Another nice trick if you're under time pressure is to arrange the project so that you can deliver it in stages that partially meet the requirements, or even deliver something non-functional that people can play with while they wait.

This can keep the sales team rolling or customers happy for a while, buying you some time to write the program properly.

As a bonus, you might get earlier feedback if you're going in the wrong direction, in which case less time wasted.

(Obviously this approach isn't always possible. Many problems won't decompose nicely.)

Re: Why software projects take longer than you think – a statistical model

#79

Post by Aeolun »

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

> But when you advocate clearly for your needs as a professional, people are generally reasonable.

This has not been my experience. People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.

Re: Why software projects take longer than you think – a statistical model

#80

Post by afarrell »

GlennS wrote: post #77
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

Well, this is some good advice. Another nice trick if you're under time pressure is to arrange the project so that you can deliver it in stages that partially meet the requirements, or even deliver something non-functional that people can play with while they wait. This can keep the sales team rolling or customers happy for a while, buying you some time to write the program properly. As a bonus, you might get earlier…

this is where it becomes crucial to know why you're building the thing you're building. That way, you can often structure the project in phases according to your engineering judgement of the way those phases are built and the business value they enable.

Then you can cut scope by postponing (or not doing) some of the phases. Ideally.

Post reply on HN