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

91–100 of 324 posts

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

#91

Post by drunkpotato »

afarrell wrote: post #61
koonsolo wrote: post #53

Earlier quoted context omitted.

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

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out o…

Hah! You just described the start of one of our products so accurately it’s scary! And then we built out the parts that were starting to fail as the product scaled. You can get surprisingly far this way!

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

#92

Post by natorion »

acd wrote: post #18

US navy has developed something similar with beta statistical distribution. You estimate "Optimistic", "Most likely" and "Pessimistic" time estimates for each task in the project and then use beta distribution on it. Some tasks take way longer than estimated. Here is the link to the time estimation described above with Beta distribution. https://www.isixsigma.com/methodology/project-management/bet...

You might also know this as PERT (https://de.wikipedia.org/wiki/Program_evaluation_and_review_...)

I used it in the past and I think it is a good framework to discover uncertainty and make it more visible, because it makes you talk about optimistic and pessimistic cases.

The estimates are also good enough to come up with a draft schedule.

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

#94

Post by arethuza »

maxxxxx wrote: post #55
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…

I once worked for CEO as a Director of Engineering who was convinced that any product feature could be implemented in 2 days - and this was a non-trivial engineering area.

That was an entertaining job.

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

#95

Post by afarrell »

Aeolun wrote: post #79
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.

This is a real thing that happens, but its frequency varies from organisation to organisation.

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

#96

Post by nmalaguti »

jfoutz wrote: post #28
iraldir wrote: post #4

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

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 my team uses Fibonacci is that it cuts down on the “is this a 3, 4, 5, or 6 point ticket?” discussion. Each larger value should have more uncertainty, so there isn’t any point in getting more precise. Not being able to argue over 1 point differences but having to choose between 5, 8, and 13 has a clarifying effect on the process.

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

#97

Post by watt »

moccachino wrote: post #73
chii wrote: post #48

Earlier quoted context omitted.

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.

I guess he was estimating the effort (billable time).

But was not estimating the actual total time until completion which must include all the lead time, waits and dependencies.

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

#98

Post by afarrell »

golergka wrote: post #86
koonsolo wrote: post #59

Earlier quoted context omitted.

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

> Does it all take that long? That's just a question. Asking questions is OK. If you have such a high need to please other people and such a low self-confidence that you will change your answer simply if someone asks you twice, that's the problem with you, not them. I say it as someone who have been like that and have changed it through therapy. I was a nervous mess and always thought that people around me don't like…

This is the core of my point. Therapy was helpful for me learning it as well.

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

#99

Post by retiredcoder »

Aeolun wrote: post #79
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.

“Let’s just put some number in those boxes”, next thing you know it is signed on blood...

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

#100

Post by mgkimsal »

afarrell wrote: post #61
koonsolo wrote: post #53

Earlier quoted context omitted.

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

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out o…

Testing will happen. The choice you make is who does the testing and when it happens. Internal people testing earlier is generally preferable to external customers testing 'live', but either way, the testing will happen.
Post reply on HN