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

21–30 of 178 posts

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

#21

Post by pydry »

steveBK123 wrote: post #15
intelVISA wrote: post #10

Earlier quoted context omitted.

> no-jira, no-meeting, get-it-done environment Best env, but sadly a bit rare? I used to select for shops like that, no wonder lay-offs are scary if you've been trapped in meetings instead of shipping.

I seem to manage getting into these types of roles 30% of the time, which is pretty nice. Granted I am working a zillion hours right now, but I'm less stressed than when I was working 9-6 but in 5 hours/day of zoom. Just feels like I am exercising my mastery vs fighting against inertia.

Something similar happened to me too. I switched from working 4 hours a day to 9 in a new job and my burnout healed.

4 hours of bullshitting, meetings, an unclear vision, constantly being blocked, anxiety over a lack of productivity was swapped with 9 hours of clear aims, clear goals and hard work.

It was still not sustainable but it felt way better.

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

#22

Post by ptrhvns »

karles wrote: post #17
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.

Because no customer wants to write a blank check. If you don't know if its 500 or 5000 hours - you're simply not buying the product.

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 without the expectation that something new will be discovered on some accurate schedule.

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

#23

Post by bonoboTP »

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 never had been foreseen, it's an impossibly hard problem bla bla. But best to bail from the vicinity of the project once reality starts to manifest itself. By that time you should be on the next project perhaps at the next company again promising the stars.

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

#24

Post by fzeindl »

I have written quite a bit about this in my blogpost https://www.fabianzeindl.com/posts/the-codequality-pyramid

Also check out this study which links software quality to deviations in estimation: https://dl.acm.org/doi/10.1145/3524843.3528091

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

#25

Post by sokoloff »

vjaswal wrote: post #19

We (or at least I) may base our estimates on the happy-path. That is, I can see how to solve a problem in the common case. But as I code, I encounter the myriad of error cases, exceptions to the common problems, and especially the interactions of all these. Then add in performance considerations and the complexity can multiply quickly. The long-tail of those errors and exceptions can be very time-consuming to solve,…

Cars and buildings are probably more loosely coupled than most HN readers imagine. Up through the engine in the 1995 Mustang (I think that was the cutoff), the Ford small block engine line would all bolt into Mustangs all the way back to 1965. I've got a 1989 block, a modern 5-speed transmission with overdrive, hydraulic clutch, disk brakes, dual circuit braking, limited slip differential, and a semi-modern radio in my 1965. All of those were either direct bolt-on or straightforward upgrades with minimal field engineering needed. Many of the VW and Audi engines also have common engine/trans mounts and interchange across years and brands. You can often bolt heavier duty suspension or brake packages onto base model cars/trucks. "Parts bin engineering" is a phrase to search on to learn more. It's done aftermarket, but it's also done by the manufacturers.

There's a similar story in the mechanical engineering for buildings. Sure, some architectural choices will make it harder or easier, but most buildings can be retrofitted system-by-system over the decades a building is in service.

Part of that is to allow configuration pre-sale, but a lot of it is just "it's too damn complex if everything affects everything else", which is not that different from software.

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

#26

Post by sideproject »

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, introducing tech debts. Engineers picking technology tools without much research, because there is no time, which increases complexity. People leaving, and then new people can't understand everything holistically. All of these factors combined into one gigantic bowl of mess.

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

#27

Post by rewmie »

vbezhenar wrote: post #18

I write code for 15 years and I still have no idea how to do any estimations. All my estimations are off by 2-200 times. Basically they’re useless. I write code until I’m happy with it. Sometimes I need to rewrite code 5 times before I’m satisfied. Sometimes I have extremely bad mood and can’t do anything creative at all, so even expecting me to work a hour tomorrow is not reliable. Or may be I’ll be in perfect mood…

> All my estimations are off by 2-200 times. Basically they’re useless.

I know, hyperboles and all, but if your initial estimate for a task is 1 week but you end up requiring 4 years to deliver it then something went terribly wrong, and asking your for estimates ain't it.

Even story points scope tasks with granularities that range different orders of magnitude for this reason. One day, one week, epic/spike. It's ok if one day means 4 days, or one week means two. If one day turns to 3 years then the developer was completely clueless and unfit to continue working on the project.

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

#28

Post by heywire »

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…

Go find a well established company where you can work on an existing product. I work on a legacy point of sale product that started life in the 80’s and is still powering a good chunk of commerce around the world. I work on a small yet efficient team who customize the product for retailers. It is all about the team you’re on though. My company is also releasing all kinds of new products and services. I doubt anyone would describe working on those teams as calm.

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

#29

Post by jcarrano »

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.

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

#30

Post by mpweiher »

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 individuals etc.).

And if there's a meeting you really really can't avoid or eliminate, let's at the very least incentivise everyone to keep it as short and meaningful as possible. By having everyone stand and thus be slightly uncomfortable.

How that fun, focused, no-nonsense, get-things-done approach got turned into ... whatever that "meeting-heavy" thing is ... is in some senses fascinating.

And terrifying.

> I'm currently in a no-jira, no-meeting, get-it-done environment

AKA, an agile environment. ¯\_(ツ)_/¯

Post reply on HN