Hacker News Reader

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.

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

I did not expect that plot twist to your story. Sounds about reasonable. Proper project management takes alot of time and need to engage the actual implementors.

> Proper project management takes alot of time

Typical proper management is based on estimations given in front of the coffee machine.

Exceptional projects have the coffee machine substituted with a wine bar.

Never have I gotten more honest feedback from a manager than after a split bowl of punch and three espresso martinis

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.

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 team that will build it, reasonble estimates can often be produced quite quickly. Obviously, there can be risk factors, such as customers or managers with unreasonable expectations, but those can typically be managed by experienced teams.

Anyway, raw estimates should never be seen as budgets. Budgets should be much larger, especially if they can be kept hidden from the developers, since budgets need to take all sorts of risks into account. But most team if they know what the budget is (and it's big enough), may tend to relax a bit too much early on in a project.

Most software projects go a bit (or sometimes quite a lot) over estimates. Which is often fine. The estimate may still have been a useful exercise, in that it forced someone to think about most details of the deliverable early on, and also provided something to track progress against.

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

This is an excellent observation.

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

I've seen it done, and it's more than double. You have to have most of the work done before you deliver the estimate. The thing is, you have to deliver an estimate that is at least as long as the time you spent producing the estimate, but you're already mostly done, so towards the end of a project there's a lot of gold plating and general screwing around. It's a silly way to work.

And everybody knows what's going on, because people talk. You can't keep it secret. You can only do it as long as upper management thinks it benefits the company. The customer-facing side of the business (sales, customer success) makes a very strong case that faster delivery means happier customers, and more optimistic timelines mean more sales. As much as accurate estimation is an eternal management dream, there's not much benefit to it other than a little bit of dubiously valuable trust and credibility with customers. The idea that "if only we could estimate accurately, we could execute grand strategic visions" is mostly bullshit. You're slowing yourself down, and the only thing you get out of it is that engineering management gets to pat themselves on the back for hitting estimates.

> The idea that "if only we could estimate accurately, we could execute grand strategic visions" is mostly bullshit.

10000x this. It’s complete bullshit.

And the bullshit is often used to shift blame to the dev team in order to cover up for a lack of management competence.

I started to think about how to describe the problem in business planning terms (ie, money) because I needed to come up with language that senior management and non-software CEOs could understand, for a series of meetings I recently attended. I realised that just saying “you can’t do it” is unsatisfying, and just leads to arguments.

“Yes you can have accurate estimates but it will >2x the project cost” seemed to resonate.

(And yes I think it’s much more than 2x too)

> 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 the end of the project (when you know, hopefully, how much was actually spent). If a project is lucky, the initial uncertainty is low and reduces monotonically over time as the project progresses, so that the estimates gradually converge on the real cost.

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.

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

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.

High is the number of freelance gigs I've foregone, because they asked me to estimate the work ahead of time on my own dime.