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

51–60 of 178 posts

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

#51

Post by magicalhippo »

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…

Depends on what you mean by calm.

I work as a developer for a company that sell a somewhat niche B2B software that integrates with a lot of customer systems. However we got several large, well-known companies that rely on our products for their daily operation (and a ton of smaller ones).

We got a lot of stuff to do, between new customers pouring in and gov't changing their systems with little warning[1] and such.

However we also don't have most of the other stuff you talk about. Sales ask for estimates, but if our provided estimates don't work for the client, say because the contract with our competitor is due in a month, then they'll work with us to try to find some way of making it work rather than force it through.

There's a lot of freedom with responsibility, so sure for low-impact stuff a developer might try some new tech to learn. However for larger shifts it'll have to be discussed in the dev group, especially if it impacts support. We do have a mature codebase so some tech dept is inevitable, but we have it as a goal to try to improve those things if we need to work on a particularly bad area of the code.

As for people leaving, in the years I've been here there's been a very stable group. So stable our customers ask us how their systems work that we integrate with, as they have much higher churn.

I don't think we're particularly unique though. But we're a relatively small company with a name that you can't flash on a CV, and at first glance our niche might sound boring.

[1]: "yea we redesigned our API, we will be doing a hard cut-over in a couple of months"

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

#53

Post by steveBK123 »

pydry wrote: post #21
steveBK123 wrote: post #15

Earlier quoted context omitted.

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.

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.

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

#54

Post by z3ugma »

ptrhvns wrote: post #22
karles wrote: post #17

Earlier quoted context omitted.

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

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

#55

Post by bombolo »

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…

agile is like the no true Scotsman. There's never a true agile :D

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

#56

Post by pif »

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.

All the successful projects I've participated in could have been managed with this simple sentence:

"After some indulging in alcoholic beverages, we have signed a contract for to be shipped on : please, do your best!"

And the outcome would have been even better if we hadn't waisted so much time in preparing detailed estimations and later inventing a justification about why those estimations were not precisely met.

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

#57

Post by distcs »

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.

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

#58

Post by pif »

rewmie wrote: post #20
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.

> 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 required, still they never get the right answer until the project is completed.

Development is what makes a project successful; planning is what makes a project late.

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

#59

Post by steveBK123 »

bombolo wrote: post #55
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…

agile is like the no true Scotsman. There's never a true agile :D

Yeah it cracks me up every time. 90% of people are like "the agile industrial complex is killing my job" and the other 10% are like "well you haven't REALLY done agile because..".

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

#60

Post by RunSet »

ptrhvns wrote: post #22
karles wrote: post #17

Earlier quoted context omitted.

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

> We are figuring out how to build something novel

Is it possible to estimate the duration of a process that has never before occurred (e.g. the construction of something novel) with any expectation of accuracy?

Post reply on HN