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

81–90 of 178 posts

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

#81

Post by whstl »

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…

I had calmness when I was individual contributor working alone on difficult long-term projects, involving both research and development.

Bi-monthly or weekly meeting with the CTO, and that was it.

Delivery was on time simply because I adjusted the work and constraints to match the expected deadline. If something wasn't possible or required compromises, I would just let the CTO know. It was often fine.

The problem for me starts when you have chaotic product people in-between business owners and you.

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

#82

Post by mmcdermott »

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?

I think a lot of engineers say they want agile and they mean it in the sense of the ideals in the Agile Manifesto (https://agilemanifesto.org/). There isn't a lot to complain about with those ideals. Working software, people, collaboration and flexibility are all very good things.

When you look at the agile frameworks that are commonly implemented (Scrum, XP, etc.) you see that however well-intentioned they are, they seldom live up to those ideals. Do we care about working software or hitting burn down numbers? Do we care about flexibility or about keeping our iteration plans nice and clean? Do we care about collaboration or about having a paper trail to cover ourselves? Do we care about people or tickets?

As agile has gone mainstream more and more experiences are bad, courtesy of Sturgeon's Law. Then you add in the fact that the bad experiences will always be amplified (after all, when things are working well they're "fine"; it's still work).

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

#83

Post by taeric »

I have two simple parameters I use to apply to all estimates. How many people are involved? And how many times has each person done exactly this thing before?

The more people involved, the more invisible work there is. Not just meetings, but handoffs and general coordination.

And things are only predictable if they are done to the point of being known things. Rehearsed activities are known activities. Even if you shake up a part of it, people that have rehearsed are more capable of dealing with the shake ups and keeping things moving.

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

#84

Post by gilbetron »

My favorite paper on this matter is: https://www.researchgate.net/publication/247925262_Large_Lim...

A crude tldr is: writing software is solving a math problem and time estimating how long it will take to solve a math problem has an infinite error bar.

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

#86

Post by Tade0 »

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…

> I'm genuinely looking for a "calm" company.

I'm contracted to the IT branch of a certain pharma company and it's been calm the whole time.

Projects are either about regulatory compliance (boring, but not challenging) or supporting research - the big brains do the thinking, while you just klaka klaka klaka away at the implementation.

A visible chunk of the latter goes nowhere and eventually gets cancelled, but everyone is fine with that.

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

#87

Post by kayodelycaon »

renegade-otter wrote: post #42
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…

In one of the Agile training courses I took we were taught the concept of "horizon of predictability". The base one is two weeks. Within two weeks you more or less can estimate accurately. Beyond the two weeks, the estimates become pretty much useless. "Three months" is not an estimate. It just can't be one in good faith.

I love those training courses and their narrow view of the world. I can be accurate with 3-month and 6-month projects.

This is because long-term projects give me the space to allocate specific kinds of mental energy and attention efficiently and have steady progress.

Short-term projects, I never know if I have the right kind of energy or attention to move forward. I often end up blocked by my brain, making my two week estimates unreliable.

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

#89

Post by tcard »

samsquire wrote: post #2

Start from an empty file and write to an imaginary API or pseudocode what you actually want to do and coding is easy and fast! I think the high level imaginary API/pseudocode of any system is straightforward and fast when you start from scratch. (Because you're not focused on detail and just intent) But when you start from an existing codebase, existing infrastructure, existing APIs, it slows to molasses. You've got…

Interesting perspective. It reminds me of Eve [1], which was all the rage over here a few years ago.

[1] https://witheve.com/

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

#90

Post by pydry »

steveBK123 wrote: post #53
pydry wrote: post #21

Earlier quoted context omitted.

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.

Yeah especially if in-office, or if theres any operational aspects of the role. It's not like having 4 hours of BS job gives you 4-6 hours/day of free time to go to the movies, gym, spend time with family, cook for yourself etc. Instead you are tied to a PC bored out of your mind. The worst thing in life is a lack of purpose and feeling lack of control.

It did mean more free time, but it also meant that the free time was infected with worries and so was much lower quality.

It was easier to put work out of my head in the latter job. Anxiety didn't overwhelm my evenings and weekends. Sunday evenings were restful instead of steeped in anxiety. It felt more like they belonged to me.

When I came home each evening I felt tired in a good way.

Post reply on HN