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

71–80 of 178 posts

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

#71

Post by jasongi »

distcs wrote: post #57
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…

> All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Depends on the workplace I guess. Haven't seen this where I've worked. quite the opposite. Some managers I've worked with taught me to multiple estimates by 2X before writing it on paper.

An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate.

The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.

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

#72

Post by 0xblinq »

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…

Same

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

#73

Post by distcs »

jasongi wrote: post #71
distcs wrote: post #57

Earlier quoted context omitted.

> All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Depends on the workplace I guess. Haven't seen this where I've worked. quite the opposite. Some managers I've worked with taught me to multiple estimates by 2X before writing it on paper.

An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate. The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.

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

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

#74

Post by steveBK123 »

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

My last place liked to bring in an astronaut or general to talk to us about things like this lol

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

#75

Post by Nowado »

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…

Are you trying to say you correctly estimate your own projects?

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

#76

Post by dgb23 »

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?

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

#77

Post by magicalhippo »

spion wrote: post #3

I've been advocating for 3-point estimation for quite a while. [1] Unfortunately it doesn't happen very often (mainly because tooling support for this has been missing in popular trackers such as Jira). In situations where I was the decisionmaker on the methodology I've had excellent success with it. (using about 90%-95% confidence interval was typically right on the mark) [1]: https://en.wikipedia.org/wiki/Three-poi…

I'm doing something similar I guess. It's more of a two-point plus uncertainty/confidence estimation. I'll give a range (2-3 days say) and I'll estimate how uncertain (or how confident) I am in that range. For larger tasks I'll break it down into smaller subtasks and estimate individually.

For example if I need to use some new library that I've never used before, my estimate for that will be quite uncertain. Perhaps the library has some weird quirks it takes time to figure out. If I have to do something I've done often, I'm quite confident in my estimate.

Effectively similar, except I don't like to estimate unknowns so I don't give an explicit worst-case time.

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

#78

Post by pmg102 »

distcs wrote: post #73
jasongi wrote: post #71

Earlier quoted context omitted.

An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate. The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.

> 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"?

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

#79

Post by Makhini »

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…

Yes, that's absolutely possible. My company is making a b2b product. We have challenges and sometimes the scope of the new features can be huge. But I never felt big pressure.

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

#80

Post by sokka_h2otribe »

z3ugma wrote: post #54
ptrhvns wrote: post #22

Earlier quoted context omitted.

I think the fundamental misunderstanding is that we aren’t building a product. We are doing research and development. We are figuring out how to build something novel, otherwise the customer could just go out and buy it already. Once we’re done with discovery, the computer builds it. So, the customer is like any other who is paying for research and development. It’s not a blank check, but they should go into it witho…

This is hubris of the field of software engineering. The no-code market and the existence of tools as old as MS Access prove that there are software projects for which a better analogy is not R&D, but construction. I do note that construction projects are also not good at estimating, but it's folly to suggest that at some level we are not _manufacturing_ rather than _developing_ a widget.

Construction is a bespoke non-factory manufacturing process. If you extend the metaphor:

Estimating large projects is a big construction projects. Those tend to be large buildings and relatively on schedule. Estimating small projects with small teams is bespoke. And more likely to go off schedule when the plumbers can't time well with the electrical services, i.e, you have a dependency on another teams API or something, similarly to how software struggles in small team open ended scope projects with unknowns. But a tightly scoped single-trade software project won't struggle just like construction.

In end, I agree with you that construction is a decent metaphor. But construction is very far from manufacturing a widget, as it's a bespoke manufacturing process with ample site specific constraints

Post reply on HN