Hacker News Reader

I gotta tell you that unless you're working with absolute bozos, nobody is looking at estimates and saying "oh duh, I am betting the farm this will complete on that date."

Happens all the time, and not just by bozos. Sometimes getting paid is entirely dependent on delivering when you said you would. I used to work at an animation studio and one year we worked on a series of Christmas themed TV spots. When we said we could deliver on time we where very much betting the farm our estimates where correct. Nobody is paying to air those in February.

Similar story, in a larger firm. There are internal incentives where teams are compared against each other and a lot of it hinges on delivering things when a team said it would.

This leads to all sorts of strategies to make that happen: from cutting corners, to underpromising, to padding estimates. In the end, the sum of it all is that nobody is able to paint an accurate picture of the capabilities of teams overall because everything is so heavily skewed by internal incentives and competition.

But they are bozos if they give you a task they want done for Christmas, you tell them that it will likely not complete until February, and they say, "well, just work harder/extra hours/hire more people", which is pretty common.

The way to avoid bozo-land is for the person asking to come back with "well, what can you confidently complete in time for Christmas?", and plan for that.

That's not an estimate, it's a deadline. Different concepts.

Not really. You have to estimate within the deadline. Estimates are often required due to such dependencies.

Surely a deadline is just an estimate you bet the farm on :)

No. You would make your own estimation. If the result is November 1, +- 2 days, you can bet the farm. If the result is December 22, +- 14 days, you should pass.

While the article is rather low quality in and of itself, it still manages to point out:

> Before claiming that the simulation above is reliable, I must expose a few things you’ll need to pay attention to when using a Monte Carlo Simulation to make forecasts:

> (A) The quality of the inputs upon which your simulations depend.

> (B) The consistency and predictability of your team.

> (C) The need to re-forecast.

> (D) The size of your work packages.

Among those, I am not exactly sure what the author is referring to with (C). However, problems arise most often when none of A, B, and D is controlled by the person being asked to estimate.

Now, if you can control A, B, and D, YOU DO NOT NEED TO RUN MONTE CARLO. You'll be able to split the work and guess within 10 - 20% just by using rules of thumb.

If you cannot control A, B, and D, running Monte Carlo will not help you.

I say this as a person who's been doing Monte Carlo since the late 80s.

We're stuck in the eternal loop: "Tech Y will save us from ourselves and having to think."

> I gotta tell you that unless you're working with absolute bozos, nobody is looking at estimates and saying "oh duh, I am betting the farm this will complete on that date."

Apparently I've worked with a lot of bozos over the last 25 years... (apologies to everyone I've worked with).

Lion tamer reporting in. It’s all circuses out there.

> I gotta tell you that unless you're working with absolute bozos, nobody is looking at estimates and saying "oh duh, I am betting the farm this will complete on that date."

I gotta tell you, you've never worked with a business stakeholder, the government (see financial penalties for missing deadlines) or with an absolute deadline (ie Christmas) if you think that's true.

> Many commenters on this story believe the main purpose of estimation is to assert when something will be done

We know our estimates can never be guarantees, but that is irrelevant to stakeholders whose career advancement depends on project X being done in day Y. Guess who's opinion carries more weight in literally every profit making enterprise.

You and a few other responses hit on a related but distinct problem: an unmovable deadline.

In this case, the question is no longer "how long will X take" but "but what will it take for X to complete by Y." That can require aggressively cutting scope, reassigning resources, de-risking in every possible way. That's quite different than asking a developer/team "how long this will take" assuming constant resources and given scope.

There is a reason project management calls scope-cost-time the iron triangle. It's extremely to bind all three sides tightly unless the estimates are very good, and/or there is significant added buffer to the project (and that really means the cost side is what's stretching to give you extra certainty on the hard scope and time deadlines).

More commonly at most two of the three are tightly constrained, and another side is more free. One can optimize in some directions, but none of the sides are fully independent of each other. I think the best project outcomes I've seen on are ones where only one side is strongly fixed, and the team is in control of the other two aspects.

You get all of the benefits that you’re looking for just by planning what needs to be done, estimations or not.

You break down the tasks, the dependencies, the risks, complications, places where there are options that need more research or comparison…and you’ll see the volume involved and have an idea of the size in the terms you mean. All without numerically estimating a single task in the plan.

> All without numerically estimating a single task in the plan.

However, often you have multiple paths to achieve a goal, and you have to choose which one you're going to take. Either you estimate each path in days/weeks/months or you'll have to compare all the alternatives (a > b?, b > c?), at which point having numbers is probably worth it.

I would also argue that enabling capacity planning and drawing a boundary around the scope are also valuable by-products.

Perfection may be impossible, but Brooks' Law being a harsh mistress, and scope creep being a very real thing, having a serious think about how big you intend the project to be to be before you start can make the difference between finishing it in months, and having it turn into a years-long death march project.

> I gotta tell you that unless you're working with absolute bozos, nobody is looking at estimates and saying "oh duh, I am betting the farm this will complete on that date."

Meanwhile, anybody working anywhere close to the retail space fell laughing off their chair. Thanksgiving won't move no matter how much you insult your co-workers.

(This is not limited to retail. Many industries have fixed delivery dates and bet on those. Thanksgiving is just the most obvious example of an immovable object)

There's a difference between "it's done now, before Thanksgiving, let's bet the farm on it" and "it might be ready two days before Thanksgiving, let's bet the farm on that"...

Ed: that said, given gp quote about working with bozos, there's always that anecdote from the introduction of (2nd éd) of Peopleware, about the deadline being moved, because the project was on track for meeting the original deadline... (March meeting: we can deliver as planned in June - project leader called back; we've moved the deadline to April - paraphrased).

The deadline is still immovable. Yes, you've planned with a buffer, but you're still betting the farm that ultimately, it will come out in time to capture that business.

And Black Friday season is large enough (30% of annual retail) that you might well try for a farm-sized bet. Been there. Done that. Had the conversations around risk.

It is both "it must be operational by this day, or huge losses" and "we would rather not ship your effort than ship it between Black Friday and Christmas".

If you supply anything that retail needs on Thanksgiving (including physical media containing digital assets), you have a very strict timeline as well. There is sometimes a possibility to pay extra to expedite a later part of the production process (ship via air instead of ship?) but that's still a big hit and often isn't even available.

>>I gotta tell you that unless you're working with absolute bozos, nobody is looking at estimates and saying "oh duh, I am betting the farm this will complete on that date."

I hate to break it to you, but it happens a lot (and yes, management structures can often work to filter absolute bozos upwards). They make all kinds of representations to customers, investors, etc. about dates that have nothing approaching this level of estimation, more of a wishful-thinking goal. And when they fail, investments, customers, jobs, and even companies are lost — often unnecessarily if better plans and contingency plans had been made.

Sadly, just because it is blindingly obvious to you and me, does not mean it is so obvious to someone in a mgt chair.

Eh, I think there is two ways this can go.

If you're really working with people who are 'so stupid' as to take estimates literally and make plans assuming guaranteed success in those times, then you probably have other leadership/management/risk problems in your company and are doomed anyway.

There are plenty of time where there's a little bit of managerial art to communicating estimates to customers and prospects. For example, if my devs say "October, the API will be available", I may share that with the client if I understand that in reality it will take the client a long time to actually start using that API in production. So I may say "Probably early November..." with the mutual understanding that that's when they'll begin to integrate but the thing may not actually be prod-ready from either of our sides till January. It's complicated!

You are making the assumption that development estimates have anything to do with when management, sales, or customers decide that they need something.

Even without mgt/sales over-promising stuff to customers based on wishful thinking and only wanting to say "Yes" to a stupid customer demand without even bothering to ask development/engineering, I've seen situations where the date is the date, period.

I've been in plenty of situations where it doesn't matter - it's an event, scheduled years in advance, national television, and the show goes on at Monday 16:00 PDT, period. Scheduling estimates have nothing to do with it. Be ready and be there, or everyone gets nothing. The only question is: "Can the team do it?".

I don't understand why commenters are so hung up on the "unless you're working with absolute bozos" part. That sentence is irrelevant compared to the rest of the comment. The three benefits listed are a great articulation of how estimates should be used. Couldn't have said it any better.

Explicitly asking for a critical path sounds better than hoping somebody will consider it while doing something else.

this is an incredibly obvious yet valuable comment but all the replies seem to be working hard to miss the point.