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

91–100 of 178 posts

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

#91

Post by drittich »

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.

Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many implementation hours and attempts later, I realized my folly, and I am not new to SQL.

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

#92

Post by mdgrech23 »

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…

I'd also add once the project gets going and leadership realizes it's starting to fall behind they'll ask what they can do to help. I'll reply w/ very real answers like we need wireframes, or language strings or this endpoint isn't ready and we don't even have a spec blah blah but that never seems to go anywhere. Anyone w/ real power is so far out of the weeds and usually busy w/ other things and those of us in the know are in the weeds and have no real power.

While I'm at it there's another thing that boggles my mind. Leaders will say this is the most important project at the company and so much is riding on this project blah blah blah and then they give you a max of 10 minutes to explain all the issues you're facing before they seemingly move on to the next thing. I don't doubt it's importance. I genuinely believe them when they say this is really important but then put your money where your mouth is, roll up your sleeves and actually start driving shit.

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

#93

Post by raincole »

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…

By this logic, programmers should be able to accurately estimate the schedule for personal projects or small scale open source projects where no one can "reprimand" them.

It's so far from reality that it's almost satire.

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

#94

Post by _ea1k »

mpweiher wrote: post #30
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…

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

Just wait until the Scaled "Agile" Framework[1] experts help to improve your efficiency with even more process overhead.

[1] They weren't even concise with the acronym. Hey, lets throw a random e on the end!

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

#95

Post by isaacremuant »

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…

That cynical take is actually quite accurate in many contexts.

People are definitely trained via bad managerial incentives to do this and end up doing it even without thinking.

It's also funny how people talk agile but then want full project estimates with milestones down the line because that's how they get to pretend that: - they can give real assurances to the customer - they're valuable PMs with a tech contribution (when it's mostly the M&M customer management and meetings, they're good at)

There's all flavours of situations and people, of course, but it's definitely a common trend in companies, even those that have high renown and are seen as leaders of an industry.

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

#96

Post by rkangel »

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…

This is definitely true in some places. I have worked on Defence contracts that worked in exactly that way - win the initial bid by being cheapest, and then have the MOD pay you to fix all the bugs later.

OTOH, it's not the culture where I work currently. We are expensive, we know we're expensive but the reason we can get away with it is because we deliver. That's on several fronts like technical capability but also because when we say "It'll cost X to get you what you want" it usually ends up costing them something close to X.

Part of doing that is that if we don't have enough information to build the thing, we might do a "Phase zero" for a fixed period of time looking at the biggest question marks and that means we're much better informed to quote the main piece of work.

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

#97

Post by dimal »

> I have two methods for estimating project size:

> (a) break things down into subprojects, estimate them, add it up

> (b) gut feeling estimate based on how nervous i feel about unexpected risks

> So far (b) is vastly more accurate for any project more than a few weeks

Here lies one of the main problems with “estimates”. They don’t capture a confidence interval. You can only give one number (and it’s usually story points, not real time). “That’s a five point story”. How confident are you in that assessment? How many unknowns are buried in there? So, a five point estimate that’s arrived at after careful consideration has the same weight as one given off the cuff with no investigation at all. Of course estimates go wildly wrong.

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

#98

Post by rkangel »

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 on a contract and schedule with the manufacturer and you need to be able to have SOME indication of where in that process firmware might be released (or more realistically - given the timescale, what scope of software is possible).

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

#99

Post by okaram »

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 have found a sure way to get estimates... Do the work, and say how long it took me.

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

#100

Post by joombaga »

okaram wrote: post #99
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.

I have found a sure way to get estimates... Do the work, and say how long it took me.

You should probably still add a week to the estimate.
Post reply on HN