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

121–130 of 178 posts

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

#121

Post by esafak »

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…

Tell them to rank the features by importance. Go down the list with individual ETA estimates and they can deduce the final ETA. For bonus points provide error bars for each item so they can see how it adds up...

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

#122

Post by esafak »

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…

Experienced people develop different things than inexperienced people. Planning could simply involving experienced people to ensure the right thing is being built.

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

#123

Post by JamesBarney »

orra wrote: post #37
mpweiher wrote: post #30

Earlier quoted context omitted.

> in a meeting-heavy agile environment Everytime I see that, I cringe. But sadly, you're not wrong. Agile is anti-meeting, anti-heavy and definitely anti-meeting-heavy. I really don't know what to call this weird thing that was created. Just as an example: why are there standups? Because in XP, meetings are frowned upon . So the idea is not to have meetings whenever humanly possible (better to pair up, talk to indivi…

Don't get me started. The agile manifesto says “individuals and interactions over processes”. So, of course a whole industry popped up of managers (and agile consultants) prescribing scrum. In practice, it's not unlike waterfall, because requirements and timetables are prescribed from above. But hey, the team has a sprint kickoff meeting every two weeks, so we call it agile.

It's so much worse than waterfall. Every "agile" shop I've worked at still had deadlines 6 months out, they just didn't give you any time to design and estimate our the work because it was "agile". They were all twice as process heavy and had twice as many meetings as the shops that didn't call themselves "agile".

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

#124

Post by mmcgaha »

alentred wrote: post #45
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…

It depends on the company, or more specifically on how the company manages the budget (people working on projects, infrastructure budgets, etc.). In many companies people would rather do the other way around: inflate their estimates to make sure that they definitely fit the reality later. This also often leads to continuously increasing budgets because or the corporate logic: “if you asked for budget but didn't use,…

I have worked with both types of managers and many in between. My perception is that the sandbagger tends to be more accurate and executives tend to respect them more. The problem for the sandbagger comes when the project is large enough to get multiple estimates and the sandbagger gets put on the spot to explain his estimate. Our current project was estimated by our former VP at 4X and an outside consultant estimated the project at X. The board called the VP in to explain why his estimate was so high. We are now well into the project and former-vp's estimate is reality and former-consultant is gone.

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

#125

Post by willsmith72 »

dgb23 wrote: post #76
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…

I don't do "Agile" and never have. But every time I read or hear about Agile it's described like above. Everyone seems to hate it and it all sounds terribly inefficient and frustrating. I scratch my head... Why? Why are people still doing it? Who actually _wants_ that?

What do you mean? I find the exact opposite. People are still wanting their waterfall project with an upfront design and "requirements analysis", and shocked when things run over-time with a crappy end-product. This also goes for SAFE and many implementations of scrum.

What don't you like about agile? What do you use that's better?

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

#126

Post by steveBK123 »

JamesBarney wrote: post #123
orra wrote: post #37

Earlier quoted context omitted.

Don't get me started. The agile manifesto says “individuals and interactions over processes”. So, of course a whole industry popped up of managers (and agile consultants) prescribing scrum. In practice, it's not unlike waterfall, because requirements and timetables are prescribed from above. But hey, the team has a sprint kickoff meeting every two weeks, so we call it agile.

It's so much worse than waterfall. Every "agile" shop I've worked at still had deadlines 6 months out, they just didn't give you any time to design and estimate our the work because it was "agile". They were all twice as process heavy and had twice as many meetings as the shops that didn't call themselves "agile".

Yeah instead of defining where we need to be in 6 months and the steps needed to get there, we micro-focus on the next 1 week of work.

It's almost like Manhattan projecting your own team, except theres no one who actually knows the full picture. Amounts to short term "wins" and constantly missing the actual target.

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

#127

Post by HeyLaughingBoy »

swader999 wrote: post #115
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…

A team I was once on would take 2-4 days to estimate how much work we could get done in the next two months. We were usually pretty close! The important thing to understand here is that we had complete buy-in from Management. This was part of our process, and they understood that we needed that time to do a good job of estimation and risk management.

The problem in most organizations seems to be that no one is willing to absorb the cost of real estimation.

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

#128

Post by HeyLaughingBoy »

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.

That's when you respond with "when do you need it done?"

And you can probably work together to see what can realistically be completed by whatever date they had in mind.

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

#129

Post by HeyLaughingBoy »

pmg102 wrote: post #78
distcs wrote: post #73

Earlier quoted context omitted.

> The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand. Planning poker creating a sort of prisoner's dilemma is an intriguing thought. Mind explaining a little how it leads to something like prisoner's dilemma. I'd like to grok the connection between the two things.

I'll have a go: If you ask developer A how long it will take, the best outcome for them is that they AND EVERYONE ELSE go high. So they should go high. BUT if everyone else goes low, but they go high, then they look bad. So they're forced to go lower. But then not too low, or they won't be able to deliver in time. So perhaps this settles on an estimate that's "as low as possible but no lower"?

> the best outcome for them is that they AND EVERYONE ELSE go high

But it's really not. The best outcome for them is that they are 100% accurate.

Now, I understand that that's generally not feasible, but assuming that you need to pad everything by a huge amount is part of the problem.

As a general rule, I've found that the kind of answer that gets the best response is on the order of "about X time to complete development, Y to get through testing, Z if you need any documentation, release notes or user instructions, I think A, B & C are risk items that could delay completion. If Sally and Jared aren't around for us to ask questions, that will also delay things so we need timely responses from them."

Give good answers and you'll find people take you a lot more seriously.

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

#130

Post by clhodapp »

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 easiest way is through ridiculous padding. If you consider carefully and think it will take a day, say it will take two weeks. If two weeks, say six months and so on.

This is the sort of thing you do when the unthinkable outcome shifts from idle workers to late delivery: Today, it's unthinkable to management for workers to be idle. If instead it were unthinkable for the project to be late, they would have to accept some risk of idleness to create that outcome.

Of course, you can always start doing prep work to de-risk the project, such as spikes, POCs, et cetera, within the planning phase. This might allow you to pad less but retain the certainty of your outcome.

Post reply on HN