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

71–77 of 77 posts

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

#71

Post by steveBK123 »

pif wrote: post #46
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 preparat…

Exactly. And even then.. We had a consulting company come in and do an entire paid discovery & project planning phase. They came back with a proposal for phase 1, which they overran by 100%.

The entire project ended in acrimony since it was a statement of work, not time & materials, so at some point they are calculating how much of a loss the project is causing them to incur.

Change requests, threats of litigation, meticulous reading of specs to see what we could try to wring out of them let us with a product that never went to production.

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

#72

Post by steveBK123 »

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

> 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. Another way of looking at it is that for most projects, the uncertainty in the estimate only reaches zero at t…

And the unlucky projects are the ones so poorly planned that the uncertainty actually grows over time as new issues are uncovered.

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

#73

Post by doctor_eval »

steveBK123 wrote: post #72
KineticLensman wrote: post #55

Earlier quoted context omitted.

> 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. Another way of looking at it is that for most projects, the uncertainty in the estimate only reaches zero at t…

And the unlucky projects are the ones so poorly planned that the uncertainty actually grows over time as new issues are uncovered.

Yes.

It’s like the old saying:

“Plans are nothing. Planning is everything”.

The work of estimating the effort for a project is worthwhile, even though the resulting estimate is worthless.

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

#74

Post by doctor_eval »

brookst wrote: post #43
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.

I’m not sure I agree, but I think it’s an interesting point.

Since management people seem to like construction analogies, I’ve started to compare software projects with tunnel projects. I understand that tunnels are notoriously late, because you really can’t tell what you’re going to be digging through - until you’re digging.

Of course, you could estimate more accurately by digging, say, a 1 meter pilot tunnel before you start the full size tunnel.

But now you’re digging two tunnels. And you still won’t be able to estimate the first one…

My point is that Hofstadter's law will apply to estimating, just as it will to the main project.

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

#75

Post by doctor_eval »

trashtester wrote: post #52
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…

Without a pretty good understanding of what a project or activity has to deliver cannot provide a good estimate, regardless of time spent. Also, if you don't know WHO will build it, and their capabilities, any accuracy is impossible. When people approach the limit of their abilities, time spent on tasks goes up exponentially. However, if someone has a very good understanding of what they're supposed to build, the tea…

> When people approach the limit of their abilities, time spent on tasks goes up exponentially.

This is an excellent observation.

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

#76

Post by davestewart »

turtleyacht wrote: post #61
davestewart wrote: post #31

Earlier quoted context omitted.

Sure! It's in Sketch, and the assets are here if you want to play: https://github.com/davestewart/davestewart-site/tree/main/co...

404 Working link: https://github.com/davestewart/davestewart-site/tree/main/co...

Thanks!

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

#77

Post by m000 »

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…

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

True. This is often justified as "we don't do requirements/design because we are agile". Which is BS. If you have no big-picture design, you just end up with a patchwork of "features".

Post reply on HN