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

111–120 of 178 posts

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

#111

Post by black_13 »

commandlinefan wrote: post #65
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.

[dead]

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

#112

Post by darrylb42 »

commandlinefan wrote: post #65
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.

I worked at one place where if the estimate for any task was over 2 days it would not get approved. Some really required two days tasks could take months. If we didn't want to do it, high estimate. If the business really wanted it they asked different devs until it was two days. Such a strange place to work.

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

#113

Post by rabuse »

moffkalast wrote: post #104
commandlinefan wrote: post #65

Earlier quoted context omitted.

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

It is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.

How so? Genuinely curious.

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

#114

Post by eschneider »

rkangel wrote: post #98
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.

> we have to learn to work without estimations. That's all well and good in a world that's pure software (and that does happen in those environments). It's not realistic in a world with lead times on physical items that are at least 1 year. For example, if you want to set up a high volume manufacturing line for a new product that takes a lot of planning in advance. You need to spend 10s to 100s of millions of dollars…

I have been told that "as long as the firmware update on the device works, the rest of the firmware doesn't have to completely work until devices start getting shipped and installed." Yes, people are playing very dangerous games out there. :(

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

#115

Post by swader999 »

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 fired for taking so long to produce those estimates.

Ask your stakeholders how accurate each estimate needs to be and how much they want to spend on estimating. Where I'm at now a simple complexity score of 1,3,5,8,13 works fine and gives us +-30% variance and predictive power for new work when translating points into time spent after about three months of work and collecting the velocity.

We spend about five minutes answering how complex is this for each story. To get a 10% variance takes the team a half day for anything non trivial. You have to go through this exercise in both extremes with the stakeholders and then you get buy in for the fast estimating.

Google Mike Griffiths cone of uncertainty for the real take on this.

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

#116

Post by denvaar »

AssertErNullNPE wrote: post #103

Management: We've got a great new project that has all the features that our users have been asking for. We need it done as fast possible, it's the number one priority. How fast can we get it done? Engineers: For all of it? At least a year, probably more. Even a subset of those features will take six months, minimum. Management: That's too long. You can have all the resources you want, we need to have it done in 90 d…

The Mythical Man Month

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

#118

Post by moffkalast »

rabuse wrote: post #113
moffkalast wrote: post #104

Earlier quoted context omitted.

It is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.

How so? Genuinely curious.

Just an intuition developed over time with experience I suppose, as long as you have a fixed team you've worked with for a while on similar projects, with requirements that don't depend on many external factors.

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

#119

Post by rnburn »

> "A reasonable model for the “blowup factor” (actual time divided by estimated time) would be something like a log-normal distribution.

Research has shown a power-law distribution to be a better fit.

See "The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution" https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4204819

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

#120

Post by HeyLaughingBoy »

rabuse wrote: post #113
moffkalast wrote: post #104

Earlier quoted context omitted.

It is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.

How so? Genuinely curious.

The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y.

The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to something they did before. Estimation is itself a time-consuming task.

Post reply on HN