6 ms·

Many commenters on this story believe the main purpose of estimation is to assert when something will be done. Then they say "this is impossible" and call the w

Many commenters on this story believe the main purpose of estimation is to assert when something will be done. Then they say "this is impossible" and call the whole exercise a waste of time, or management abuse. 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." Benefits of estimation that are more important that the date itself: Enabling trade-off analysis: If you tell me the thing will be done in two months, I bucket the thing in my head as something that takes "a few months" as opposed to "weeks" or "years." Often that is enough to drive a build/pass decision on the feature. Dependency visualization: If I don't ask you to estimate, you might just start coding. Estimation may force you to think about critical paths and dependencies, then we can plan for them to improve your chances of success. Troubleshooting: why did we miss an estimate? A task was harder than we thought, that's ok. We missed a dependency, ok that's a prompt to think about those better next time. Developer keeps getting distracted, maybe we need to change something on the team. Estimation is just "calling a shot" which then enables us to (maybe) learn from missing it. All those things are valuable even if the actual estimated date is missed, even by a lot.

markmaglana 5y ago
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.
nanis 5y ago
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.
- canadianfella 5y ago
  > in and of itself What’s the point of adding these words?
- _y5hn 5y ago
  We're stuck in the eternal loop: "Tech Y will save us from ourselves and having to think."
mumblemumble 5y ago
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.
brightball 5y ago
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.
- giovannibonetti 5y ago
  > 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.
toss1 5y ago
>>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.
- xyzelement 5y ago
  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!
  - toss1 5y ago
    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?".
mgkimsal 5y ago
> 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).
- hinkley 5y ago
  Lion tamer reporting in. It’s all circuses out there.
dagw 5y ago
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.
- radicaldreamer 5y ago
  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.
- cratermoon 5y ago
  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.
- listenallyall 5y ago
  That's not an estimate, it's a deadline. Different concepts.
  - _y5hn 5y ago
    Not really. You have to estimate within the deadline. Estimates are often required due to such dependencies.
  - dagw 5y ago
luckydata 5y ago
this is an incredibly obvious yet valuable comment but all the replies seem to be working hard to miss the point.
groby_b 5y ago
> 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)
- e12e 5y ago
  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).
  - groby_b 5y ago
    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".
- HWR_14 5y ago
  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.
alangibson 5y ago
> 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.
- xyzelement 5y ago
  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.
- digikata 5y ago
  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.
8note 5y ago
Explicitly asking for a critical path sounds better than hoping somebody will consider it while doing something else.

markmaglana 5y ago

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.

nanis 5y ago

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.

canadianfella 5y ago
> in and of itself What’s the point of adding these words?
_y5hn 5y ago
We're stuck in the eternal loop: "Tech Y will save us from ourselves and having to think."

mumblemumble 5y ago

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.

brightball 5y ago

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.

giovannibonetti 5y ago
> 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.

toss1 5y ago

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

xyzelement 5y ago
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!
- toss1 5y ago
  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?".

mgkimsal 5y ago

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

hinkley 5y ago
Lion tamer reporting in. It’s all circuses out there.

dagw 5y ago

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.

radicaldreamer 5y ago
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.
cratermoon 5y ago
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.
listenallyall 5y ago
That's not an estimate, it's a deadline. Different concepts.
- _y5hn 5y ago
  Not really. You have to estimate within the deadline. Estimates are often required due to such dependencies.
- dagw 5y ago

luckydata 5y ago

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

groby_b 5y ago

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

e12e 5y ago
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).
- groby_b 5y ago
  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".
HWR_14 5y ago
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.

alangibson 5y ago

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

xyzelement 5y ago
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.
digikata 5y ago
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.

8note 5y ago

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