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

51–60 of 324 posts

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

#51

Post by wiz21c »

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…

>> and then standing your ground when they pruessure you to lie to them.

spot on.

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

#52

Post by nnq »

thatoneuser wrote: post #8
hnzix wrote: post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.)

Problem is the fact that you can only justify with a straight-face 45% (100%/220%) of the estimate you give to the client... Then you need to get clever at "bluffing" your way at "inventing" another extra +35% of work that you can't imagine/explain, but you know for sure that will come out of the blue - you know there's this extra 35% work needed for sure, you just have no idea what this work will be. Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. There's two ways to see the same math:

  (1) 45% + 35% + 20% = 100%
  (2) 100% + 100% + 20% = 220%
The world would be a much better place if clients / managers / project owners etc. would just accept that 55% of time & cost for software dev is unknown-unknowns type of unexplainable/unimaginable-at-project-start-stage-work. That's just how it is! If the problem was really clearly defined and understood, there would likely already be an off-the-shelf software solution for it that could be used instead of paying developers to build custom software!

If we could just be honest with people and show them formula (2) instead of a make-up-ladden version of (1). But people don't, so we get to play the damn elegant-bullshitting game over and over again...

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

#53

Post by koonsolo »

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…

I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later". Me saying that only the developer is able to give a realistic planning, was probably received as "developer wants to push the deadline back in his negotiation".

In the end, his company went bust because he was selling stuff to customers that could never be delivered on time, or even never at all.

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

#54

Post by js8 »

tumetab1 wrote: post #45
jfoutz wrote: post #28

Earlier quoted context omitted.

there is an uncharitable response to this thread, which is marked dead. I do think there is a kernel of truth in that response, which is nothing more than mocking. why fibonacci? I think it's reasonable to say time includes an exponential error. an estimated 1 hour task is very different than an estimated 1 week task. i see that 1 hour, 1 day and 1 week estimates are progressively, and likely exponentially, worse. Is…

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.

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

#55

Post by maxxxxx »

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…

I'm on a project right now and I am telling people "I don't know how long it will take because nobody here has ever done anything like this. The only thing I can tell you is that nobody is wasting time and we are solving problems as quickly as we can. Look at the JIRA board and see what we have done and what we are planning to do and make your own estimate". So far I haven't been fired. I also refuse to stop work and start long planning meetings like I have seen in previous projects.

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

#56

Post by afarrell »

tonyedgecombe wrote: post #50
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. You should do all this but there will still be times when people are unreasonable, it's just human nature.

Right, thats why steeling yourself for the possibility of having to deal with unreasonableness is important. If you run into it, the first step to dealing with it is to get someone to explain what they expect clearly, in relevant detail, and non-hyperbolically. This short-circuits the possibility of mere misinterpretation. They might have just been expressing their emotions but not yet grappling with their desires in concrete terms—doing so might bring them back down to earth. Then you can resume jointly problem-solving.

If that doesn’t work...I’m actually not sure. But I just started reading the book Crucial Conversations and it claims to have a relevant answer.

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

#57

Post by maxxxxx »

scandox wrote: post #49

In the world of small medium projects often the major issue is that software engineers give estimates for writing the software but customers take that to mean time to actual delivery in production and a lot of the time have no idea how big a task deployment and integration are...or don't even have a plan for that.

in medical devices it usually takes five times as long to really finish the project vs. finishing development.

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

#58

Post by maxxxxx »

hnzix wrote: post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

My number is 5. Maybe my estimates tend to be a little optimistic :-). But in general I can look at something for a few minutes, make a quick estimate (maybe ask somebody else), multiply by 5 and be pretty close to the eventual time it will take.

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

#59

Post by koonsolo »

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…

> They probably don’t want you to lie, but there is a small chance that they pruessure you to.

In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague:

PM: "We need to have X as soon as possible, how long will it take you?"

Dev: "Oh that's, easy, I can finish it tomorrow."

PM: "Tomorrow??? That's impossible, because it needs a and b, no?"

Dev: "Yes you are right... I can probably finish it by next week."

PM: "Next week??? That is a long time! It's only a, b, c and d that needs to be done. Does it all take that long?"

Dev: "You are right, I can probably finish it sooner. I can get it ready by this Friday."

PM: "That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Thanks!"

I overheard that story (open office), and it was a real facepalm moment.

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

#60

Post by teddyh »

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/evidence-based-sch...

Post reply on HN