Hacker News Reader

Comment by gilbetron | Hacker News Reader

Three months ago I found myself in yet another discussion with a PM about time estimation. I gave him an analogy I use for non-developers, where you try to estimate how long it will take to pack a kitchen into boxes for moving, the catch, I said, is that there's a significant chance each time you open one of the cupboards or drawers there might be a whole other kitchen or even house behind it.

He responded with, "well, we just have to figure out which doors have kitchens behind them, that's all!"

But during this discussion, I could feel the weight of the countless times I had already had a similar discussion in the past and it was heavy on my soul. Seriously, it feels like we've made no progress at times.

Even here, at HN, I've several times brought up the paper "Large limits in software estimation" and been downvoted as not getting it.

View on HN

I like to use civil engineering analogies too. This cupboard one is great, I'll have to remember it.

Like for people who want a 50% demo at a 50% timepoint, asking if they'd ask to drive a truck halfway across a bridge when it was half completed. I mean, you could build a bridge that way, but it would be way easier to lay all the foundations first, then build support structures, then finally pave it at the end.

Another one is when someone asks to tack on a feature on top of some system that really can't support it, comparing it to asking to build a second story on a tent. They wanted the cheapest, quickest to set up, lightest on resources system, and that required certain tradeoffs. To build their new feature, it would often be easier, quicker and safer to rewrite the whole thing from scratch.

The problem here is the PM does not see himself a part of the team, your team, but is on 'other' team that is driven by other gears. The estimates is just an input for his process flow.

What's missing is another stream of input that should externalize the constraints and barriers in the flow of both yours and his teams. Even then, as long as PM does not see himself part of your team, all this is in vain, you'd be speaking foreign languages no matter the analogies.

I've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.

Depending on the PM I've found giving a confidence level on an estimate to be helpful. For example on a task I've done a million times I might estimate that it will take me 1 hour with 95% confidence. Other tasks I might estimate at 2 weeks with 50% confidence, same task 3 weeks at 85% confidence. As with all things communication, the audience matters and it's incumbent on the speaker to communicate in a way the audience can understand. So that might not work with everyone.

Some of it I think is also personal confidence. If I tell someone it'll take me two weeks, I never budge unless new information becomes available. If you budge, you are welcoming being pressured/bullied into working overtime and/or delivering poor quality all the time to meet infinite demands. Also, we must accept that most customers are willing to accept lower quality/higher risk than we want to deliver. In this case what's important is to state the risks as plainly as possible and set boundaries on what you're willing to do before those risks come back at you.

I think the problem there is that the uncertainty bounds can be massive. Almost every task will have the form:

"This task should take a day. But if the feature of the framework I plan to use turns out to be buggy, it might take a month. A bug is unlikely but not impossible, I handwave a guess at 10%."

This sort of estimate might be reasonable, or not, depending how fractal you want to get with the backup plan of a month of tasks which themselves have wide uncertainty estimates. But it's also quite useless for planning. You end up with a Gantt chart that says "this project might take 3 months, or 5 years", which helps nobody.

Hence #NoEstimates

I don't think that people are good at that. I've been asked before to give a low and a high scenario, but all I can really do is to tell you how long I think it would take (I did a +/- 50% of the estimation, and explained what I did).

Sometimes there's a specific uncertainty that changes radically the estimation. But remove this uncertainty and we're back at estimating and doing +/- 50%.

It's the unknown unknowns that really make estimates inaccurate. If someone were an expert in one exact thing and that's what they worked with day in and day out, then those unknowns would be small and the areas around them well defined.

It is relatively easy for someone to become a maintainer of one specific thing as long as that's the only thing they're doing for a long time.

Then you look at a software developer, sysadmin, anyone in the technical industries, and quite often it's not one specific thing, it's LOTS of specific things. Each with thousands, maybe millions, of human-hours in their development and the development of the things they depend upon. Every layer of hardware and software having it's own quirks and wrinkles.

It's like trying to be the god of a small solar-system of interacting planets each with plate tectonics and life-forms.

Beta distribution is a bit better, which is basically what you are talking about:

https://www.isixsigma.com/methodology/project-management/bet...

That model is too complicated for tiny minds. Just tell me when it will be done, man!

Yep, PERT is what we use internally for estimating client work.

https://en.m.wikipedia.org/wiki/Three-point_estimation?wprov...

Reply on news.ycombinator.com