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 (2019)

erikbern.com

Post reply on HN
Print view View original

61–70 of 178 posts

Re: Why software projects take longer than you think: a statistical model (2019)

#61

Post by coldcode »

bonoboTP wrote: post #23

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…

My last employer required us to do project-long estimates based on whatever they asked for up front. However, they then felt like changing everything on a daily basis, making the estimate pointless.

Re: Why software projects take longer than you think: a statistical model (2019)

#62

Post by pixl97 »

jcarrano wrote: post #29
bonoboTP wrote: post #23

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…

Some questions are asked expecting a particular answer, rather than the truth. "How long is this going to take" is one of those.

If you get to the destination too quickly someone will make your destination farther away and harder to reach.

Re: Why software projects take longer than you think: a statistical model (2019)

#63

Post by quickthrower2 »

pif wrote: post #8

What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates. Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.

You estimate as a forcing function to know what you are trying to accomplish. The nuances of scope, how to do it and tradeoffs get discussed.

I think estimates are a problem where you have say 10 estimates, you add then up to 47 days, divide by 3 people, call it 16 days… ah about 3 weeks that’ll be done. That is dumb!

But as an order of magnitude it is useful.

Re: Why software projects take longer than you think: a statistical model (2019)

#64

Post by kulikalov »

sideproject wrote: post #26

I'm genuinely looking for a "calm" company. Is there such a thing? I have a few anecdotal stories of companies being absolutely chaotic (my current one included). I don't know where to point fingers to. I could start at pointing myself. Customers demanding custom features. Execs and sales people asking for unreasonable estimates. Engineers not feeling safe enough to say "no" but have to make something work, introduci…

That might be unrealistic in some cases but one way to deal with this is to take control over the situation. If you have a recipe to fix a particular problem whether it’s about unrealistic expectations or people not feeling safe - propose it, take full responsibility for the implementation and push it through. It takes a long while though.

Re: Why software projects take longer than you think: a statistical model (2019)

#65

Post by commandlinefan »

bonoboTP wrote: post #23

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…

> if you gave accurate estimates, you'd get reprimanded

I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.

Re: Why software projects take longer than you think: a statistical model (2019)

#66

Post by commandlinefan »

coldcode wrote: post #61
bonoboTP wrote: post #23

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…

My last employer required us to do project-long estimates based on whatever they asked for up front. However, they then felt like changing everything on a daily basis, making the estimate pointless.

> making the estimate pointless.

If it's any consolation, the estimate would have been pointless even if they never changed their minds about anything too.

Re: Why software projects take longer than you think: a statistical model (2019)

#67

Post by commandlinefan »

steveBK123 wrote: post #7

Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…

Management has a solution for that, though - they'll bring in an efficiency coach who will talk to you for an hour insisting that every time you say "I can't", replace that with "I will".

Re: Why software projects take longer than you think: a statistical model (2019)

#69

Post by commandlinefan »

ramses0 wrote: post #43

Conversely: “chicken nugget” estimation. Traditional agile suggests “sizing each task” (work estimated to be less than one sprint). I’ve found that simply “counting each task” is more effective... instead of trying to estimate the difference in sizes, it's easier and more accurate to try to divide the work into similarly sized chunks. There may be "the usual" variation around delivery pace, but at the end it all aver…

This kind of cheerleading is a big hit with the people who consume estimates... not so much with the slobs stuck producing them.

Re: Why software projects take longer than you think: a statistical model (2019)

#70

Post by magicalhippo »

pif wrote: post #58
rewmie wrote: post #20

Earlier quoted context omitted.

> What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates. Obviously, planning is critical. Planning means resource allocation. How is this not a critical aspect of any project? The mistake you're making is presuming that if estimates are not crisp then…

> Obviously, planning is critical. Considering it very often fails even for successful projects, obviously, it is not. > This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required Your line of reasoning is detached from reality. The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are req…

> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.

They don't know the true answer until the project is complete.

If my boss asks me how much time I need to integrate with some client system and I say I estimate one week, then if it's ready after four weeks that might be just fine for my boss.

My boss knows that there are factors that can affect the delivery of a project. What he almost always wants to know is are we talking days, weeks, months or years?

> Development is what makes a project successful; planning is what makes a project late.

So when you travel to new places, you just head in the compass direction? No looking at maps or similar?

Post reply on HN