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

141–150 of 324 posts

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

#141

Post by mcherm »

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.

> 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.

I like to handle this problem by providing an estimate RANGE.

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

#142

Post by afarrell »

jshowa3 wrote: post #132
golergka wrote: post #86

Earlier quoted context omitted.

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

It actually is a problem with them because when someone asks "Does it really take that long?", they're implying that it shouldn't. Of course, in reality, they have no idea either and if they're asking you how long it should take, they should accept your answer, not try to weasel out less time. But are they ever going to admit that they have no idea and accept your estimate on face without playing BS mind games? Proba…

It can also be that they flubbed at communicating and meant to ask, “what are the things that make it take that long?” Underlying that question would be, “are we on the same page about the scope of this?”, “Are you making business assumptions that I can actually provide updated information about?”, and “Are you lacking resources/clarity that I can get delivered to you?”. Thats a charitable interpretation but it’s occasionally the correct one.

It might also be that they’re surprised at the complexity and want to know more. For this reason, the important part of an estimate isn’t the number. Its the task-breakdown and the identification of risk.

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

#143

Post by taneq »

chii wrote: post #128
taneq wrote: post #121

Earlier quoted context omitted.

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.

That's the difference between a research project and an implementation project. Research, you don't know Y, Z, W, or Q. Implementation, you know the full path from spec to deliverable.

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

#144

Post by taneq »

watt wrote: post #97
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 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.

This is another part of the whole 'communication with clients' thing. You have to be clear whether you're talking coding time or wall-clock time. To be safe, give both.

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

#145

Post by mlthoughts2018 »

I’d also add that the reason why the mean will be larger than the median is usually hard to discern for any specific situation.

This foments bikeshedding debates that are a mix of business pressure to favor uninformed estimates and disagreements about which possible sources of surprises or hitting a wall are most likely.

As soon as you mix this with a formal estimation system like Agile (yes, even the platonic ideal ‘agile’ too), it creates a snowball effect of time wasting because overhead is so frequently required to resolve debates and placate business pressures for estimates.

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

#146

Post by lostctown »

crazygringo wrote: post #136
thatoneuser wrote: post #8

Earlier quoted context omitted.

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.

> then you aren't learning from previous mistakes ??? The doubling-it is for when you build the whole component on top of a library, then discover that the library has a fatal bug you can't work around, and you have to rebuild the whole component on top of a different library, then discover that other library has another fatal bug, so now you need to include both libraries with logic around when to use which one, and…

Going through this now and boy is this true. Nothing like rewriting a 1k+ lib the day before a feature is supposed to be ready and then praying you didn't blow up some other lesser documented part of the code.

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

#147

Post by ddalex »

danmaz74 wrote: post #123
cs02rm0 wrote: post #90

Earlier quoted context omitted.

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.

That's a bingo! It's never No! It's "Sure, this is what it entails and this is how much it costs". Especially if you're a contractor. If their willing to pay the price, why not take the money and do the work?

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

#148

Post by afarrell »

chii wrote: post #128
taneq wrote: post #121

Earlier quoted context omitted.

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.

Which is part of why I think the most valuable part of an estimate isn’t the number. Its the task breakdown and identification of risks.

1) You improve your foresight so you can get your manager rolling on getting resources early.

2) You have a concise record of what you think you need. If you notice something else mid-project (which does happen even in otherwise-straightforward implementation projects), you have a concrete point at which to raise a flag to stakeholders.

If you have zero confidence in an estimate from the beginning, then there is no point where its natural to realize “oh hey, this is going to overshoot and I need to communicate about it.”

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

#149

Post by dTal »

werbel wrote: post #117
adrianmsmith wrote: post #110

Earlier quoted context omitted.

Ok cool but if they have to deliver it, they’ll look like fools in the long run when they can’t, and in the end they’ll see you’re right? So it’s a win for your reputation in the long term I think?

My guess is no one will look back and say "Huh, he was right". The only thing that probably is going to happen is "Huh, why isn't that delivered?" and then they will look everywhere but on the fact that it was, at least partially, just a stupid idea in the first place. Of course I don't know the exact situation so it's more of a thought on what happens in general in the industry.

At the risk of a totally uncalled-for derail into politics - this is a hilariously apt description of Brexit. It makes me want to reanalyze the entire situation from a project-management perspective. It suggests a possibly illuminating metaphor: party leaders = management + sales, the electorate = the customer, and representatives = developers and engineers.

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

#150

Post by artworx »

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 highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers.

The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates... please don't look at the answers, I guarantee you will have fun completing it.

For clients, my preferred approach is to show "The Cone of Uncertainty" and ask where they think they are. Since most people have no idea what they want to built I ask if its ok if my estimates are 4x off. That usually gets me a few weeks of peace while a team comes up with a product definition and we start all over again :)

Post reply on HN