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

121–130 of 324 posts

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

#121

Post by taneq »

bigiain wrote: post #101
moccachino wrote: post #73

Earlier quoted context omitted.

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 see exactly the same routine in our game. "Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first." 2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.

Oh yeah. This is why I'm always very careful about quoting prerequisites for any deliverable. "We can do X in 5 weeks after receipt of Y, Z and W." Then when they say "why don't we have X," I politely inquire after Y, Z and W.

The most important part of this process is getting it in writing so that you can slap them with it later.

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

#122

Post by DougWebb »

nocturnial wrote: post #107

Wouldn't it be more sensible to give a range instead of a fixed date? I know it's not going to happen, but I think it would be more informative and honest. That way you could communicate better of how certain you are. There's a difference between telling something will be completed in, for example, 6 month +- 2 weeks. Or something will be finished in 6 months +- 1.5 months. The estimated time is the same but communic…

In my experience, developers understand and appreciate range-based estimates. But when those numbers start moving up the communication chain, some non-developer is going to either not like or not understand the point of the range, and will convert it to a single number: either the first one, the last one, or the average. They might even be honest about it, thinking "I need to know the earliest possible date, so I'll use the low end". But then the next person, who doesn't see the range, thinks that low end is THE committed date and will plan accordingly. Now your deadline is 99% likely to be missed.

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

#123

Post by danmaz74 »

cs02rm0 wrote: post #90
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 find you have to do this, but it can damage professional relationships. Recently I've flat out said no, as gently as I could, to doing some work - porting a software stack to run on Windows. A customer is asking for an estimate to do it, because a project manager who wouldn't be developing or supporting (or even using) the system likes Windows. The sales manager isn't thrilled with me over it. So he's asked the tea…

An alternative to flat out saying no is to point out how expensive and risky what you've been asked would be, in terms of development time, maintenance, and other metrics that the business cares about. Even very rough estimates with a list of risks will usually do.

If somebody else comes out with a much lower estimate, ask them what they think about risk A, B, C... if you've got a point, this will usually work.

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

#124

Post by maxxxxx »

arethuza wrote: post #113
mgkimsal wrote: post #102

Earlier quoted context omitted.

curious about this person's reaction to things not being implemented in 2 days. did he/she think that people were just dragging their feet? or not as smart? or sabotaging things to make him/her look bad?

He just edited it out from his version of reality! In fact, in all the time I was there (roughly a year including a major new product launch) I don't think anything was ever done in 2 days. Another interesting characteristic he had was to get upset if he thought projects were running too smoothly...

We have a manager who seems to think that the only way to get good performance is to set impossible deadlines. There are no consequences for missing but it’s pretty unpleasant and stressful to have to deal with this.

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

#125

Post by biql »

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 gold. Besides, if someone doesn't react well to your honest estimates, this is probably a red flag and you're better off letting them find someone else. After all, this is supposed to be in everyone's best interests.

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

#126

Post by helloindia »

arendtio wrote: post #64

Well, I think this is a complex topic. Not because of the math, but because the key to an accurate estimate is to understand who has done the estimate and on what basis. As stated in the summary, the core driver for inaccurate estimates is uncertainty : > Tasks with the most uncertainty (rather the biggest size) can often dominate the mean time it takes to complete all tasks. There are different sources of certainty:…

On the experience part, this happened to me few times, when the project manager asked me for an estimation, i give it from my perspective and experience, and then he gives the work to someone else with no experience, and obviously takes more than estimated.

Now, i always give two estimates: An estimation if the work is done by me, and an estimation if the work is done by someone else.

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

#127

Post by Spooky23 »

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…

End of the day, this is what agile is. By accepting scope items in small batches, you end up done.

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

#128

Post by chii »

taneq wrote: post #121
bigiain wrote: post #101

Earlier quoted context omitted.

I see exactly the same routine in our game. "Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first." 2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.

Oh yeah. This is why I'm always very careful about quoting prerequisites for any deliverable. "We can do X in 5 weeks after receipt of Y, Z and W. " Then when they say "why don't we have X," I politely inquire after Y, Z and W. The most important part of this process is getting it in writing so that you can slap them with it later.

> after receipt of Y, Z and W.

the problem comes when you didn't know you need Y, Z or W until the work actually starts.

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

#130

Post by snarf21 »

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 agree with you but like others have said, they want a date they can sell to and in the end it will be your fault.

It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much.

I read something once that has stuck with me. "We can never give more than a vague guess because we are literally building something that doesn't exist and has never been built before."

* I do find it annoying that the sales teams generally drive this. I wonder how they would feel about a response of "We'll get you an estimate of when it will be available as soon as you get us an estimate of when this feature will generate the $1M of revenue to cover the costs of building it. Also, please give us a list of customers that are likely to buy it and your expected contract date so we can track it along with development."

Post reply on HN