Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The work is never just “the work” (2022)

davestewart.co.uk

Post reply on HN
Print view View original

41–50 of 77 posts

Re: The work is never just “the work” (2022)

#41

Post by bazmattaz »

davestewart wrote: post #2

The article description is "A deep dive on why projects always overrun and a framework to improve future estimation" This was a personal investigation into my faulty estimation skills, off the back of a small project which became a medium project, which became a large project with no shortage of surprises, overruns and pain. The blog post was born from an honest and thorough postmortem where it turns out most of the…

Thanks Dave, as a PM this is super useful to me to help me emphasise with my team.

I love your illustration of the work involved to get a project live. I think I might bookmark this for when I encounter that pushy stakeholder that wants a fixed estimate

Re: The work is never just “the work” (2022)

#42

Post by doctor_eval »

I’ve come to the recent conclusion that estimating is not so much hard, but uneconomical.

The amount of time/effort required to create a reliable estimate would probably double the cost of the completed project (ie, even after taking into account the overshoot on the informal estimate). The number of failed projects as a percentage of all projects would fall, but less projects would even start.

We conflate “can’t estimate” with “not willing to do all the work necessary to create an accurate estimate” because we know that it’s easier and more economical to just jump into the code, than it is to do a deep, formal analysis.

What’s really happening is that we are giving up accurate estimates to reduce overall cost.

Unfortunately, businesses only see the overshoot on time (which they incorrectly equate with project cost) and not the actual undershoot on budget relative to a project that has been fully planned.

(Note that I’m not really talking about waterfall. More “plan to build it twice, because you will anyway”)

Re: The work is never just “the work” (2022)

#43

Post by brookst »

doctor_eval wrote: post #42

I’ve come to the recent conclusion that estimating is not so much hard, but uneconomical. The amount of time/effort required to create a reliable estimate would probably double the cost of the completed project (ie, even after taking into account the overshoot on the informal estimate). The number of failed projects as a percentage of all projects would fall, but less projects would even start. We conflate “can’t est…

I would agree if the distribution of errors in estimates as normal with the mean estimate and reality matching.

But if estimates are consistently wrong in one direction, even accepting greater variance, that says the process is broken, probably missing a feedback loop to learn.

Re: The work is never just “the work” (2022)

#44

Post by brookst »

xyzzy123 wrote: post #33
throwaway892238 wrote: post #15

Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…

Note that asymptotically, believing that work is worthless is the same as ignoring it. I think this is interesting because in theory there is an infinite amount of potential work that everyone is ignoring at any given point.

Thanks. I just woke up and you're telling me I might as well go back to sleep since statistically I will make zero progress today.

Re: The work is never just “the work” (2022)

#45

Post by pif »

bazmattaz wrote: post #40
creakingstairs wrote: post #11

Earlier quoted context omitted.

> I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away. This mentality and Agile mixed together creates monster technical debts. A team is rushed to create an MVP. Since it’s an MVP, things are skipped, rushed and riddled with edge cases. This is fine if the team can now use the customer…

As a PM I feel seen. So many past experiences in companies with poor product culture where this happens. Companies like to say they’re hot on agile and have a strong product culture involving mvp, test, learn, iterate frameworks but in reality so many are just; mvp, test, learn, release, move on to the next different mvp Leadership often say they want agile processes and iteration but at the end of the day they just…

> but at the end of the day they just want releases of new features

I do not understand how this reality could surprise any professional developer.

Code quality, clean architecture, elegant algorithms, technical documentation, unit tests... they do not sell. Whatever my process is, if it is not aimed to a constant output of new features and bugfixes, then my process is not good, and I am an idiot to insist on respecting it.

Re: The work is never just “the work” (2022)

#46

Post by pif »

doctor_eval wrote: post #42

I’ve come to the recent conclusion that estimating is not so much hard, but uneconomical. The amount of time/effort required to create a reliable estimate would probably double the cost of the completed project (ie, even after taking into account the overshoot on the informal estimate). The number of failed projects as a percentage of all projects would fall, but less projects would even start. We conflate “can’t est…

A few years ago, our management summoned some contractors to enlighten us on how to properly estimate a project. They taught us The Way (TM), and proudly stated that they were renowned for their respect of the deadline.

I wasn't snarky enough to remind them that shipping is extremely easy when you take no responsibility for maintenance, but I expressed my curiosity about how much time would be devoted to the preparation of the estimation itself.

I appreciated their honesty when they replied that, for a typical 1000-hour project, 250 would be devoted to the estimation.

I then strolled back to my boss and thanked him for letting me enter the Illuminati circle, and showed my impatience for showing him my progress with the next project. I promised him the best estimation he would ever get, and just warned him: "It usually takes us two years to develop a new machine. Next time, just let all of us (~100 people) disregard any other task and focus entirely on the estimation, and in six months top you will know whether the new machine is feasible."

He was not thrilled.

Re: The work is never just “the work” (2022)

#47

Post by zmgsabst »

TeMPOraL wrote: post #28
spockz wrote: post #22

Earlier quoted context omitted.

In find that even though I’m typically pretty spot on in the amount of actual design and coding time a feature requires, the actual wall clock time can be way off. Ad hoc meetings, days off for holidays/corporate events, waiting on external feedback, etc. are all very hard to account for.

Something I realized while skimming this thread, and moments before opening the article itself - I'm definitely underestimating things by factor of 2x, because I keep forgetting about the denominator - that my one work day isn't really 8 people-hours of project work! In reality, it's closer to 3-4 people-hours on average, after I account for time consumed by team meetings, corporate paperwork, 1-on-1s, code reviews,…

I have the same 3-4 hour estimate, but I think this stood out to me because of working a labor job as my first:

- 8.5 hours on site

- 1 hour of breaks + lunch

- 30 minutes of getting into/out of lunch (tidying up + restarting)

- 30 minutes of gathering tools/supplies in the morning

- 30 minutes of putting stuff away at close

- 30 minutes walking around/getting stuff you didn’t expect to need

- 30 minutes of talking to boss/coworkers about their problem or yours

So you’re talking 5 hours of “real” labor in an 8.5 hour day — and that’s on days you have a consistent project. Days where you have a bunch of small tasks all over the apartment complex might be 3 hours of “swinging hammers”.

That’s normal — and I think people tend to forget process when estimating things.

Re: The work is never just “the work” (2022)

#48

Post by davestewart »

bazmattaz wrote: post #41
davestewart wrote: post #2

The article description is "A deep dive on why projects always overrun and a framework to improve future estimation" This was a personal investigation into my faulty estimation skills, off the back of a small project which became a medium project, which became a large project with no shortage of surprises, overruns and pain. The blog post was born from an honest and thorough postmortem where it turns out most of the…

Thanks Dave, as a PM this is super useful to me to help me emphasise with my team. I love your illustration of the work involved to get a project live. I think I might bookmark this for when I encounter that pushy stakeholder that wants a fixed estimate

You're very welcome!

Re: The work is never just “the work” (2022)

#49

Post by gjadi »

Here are the factors proposed by Code Complete (2nd edition):

- baseline: a program, designed by and destined to the same entity (programmer = customer) - a product (3x): designed by an entity destined to another entity (customer). - a system (x3): 2 programs communicating with each other - a system product (x3x3=x9): a system of 2 products

Re: The work is never just “the work” (2022)

#50

Post by toyg »

Cerium wrote: post #38
throwaway892238 wrote: post #15

Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…

I have a story about the boss: years ago the boss walks over to me and describes a straightforward change with priority that it should start right away. I said it was a two or three day job and that considering testing and other internal process could be confidently delivered in two weeks. "That's too long, never mind". I then overhear him asking a coworker about the same project. He says: "Easy, that is a two or thr…

Congratulations! You've just gone through a crash course of Bidding On Enterprise Projects, For Dummies.
Post reply on HN