4 ms·

>4 days becomes 5 weeks Are you being serious? That only works if the people consuming these estimates don't have a clue and therefore can't call BS. This woul

>4 days becomes 5 weeks Are you being serious? That only works if the people consuming these estimates don't have a clue and therefore can't call BS. This would get me aughed out of my job.

RealityVoid 9y ago
This also astounds me. I can't graps the art of these estimates. I suck at estimating deliviery times, and I'm a pretty good engineer. But I either over-estimate or under-estimate, I find it hard to be on point, there are always unexpected side effects. And I'm known as a sort of miracle worker, when they have something they can't solve, they come to me. But I HATE giving estimates. If I were to estimate things as suggested in this thread, it seems to me things would never get done. Ever. It simply boggles my mind people want and will fudge estimates on this scale.
- falcolas 9y ago
  Pretend, for a moment, that you're working on a one week project. You're estimating that week based on the ability to use an open source project which promises to take care of a large portion of the complexity for you. Also pretend you're new enough to not realize the hollowness of that promise. It's only three days in to the project that you realize there's a mismatch between what you need and what the project provides. You start a conversation with the project's lead developer; but they're only able to have half of any given conversation in a day. How hard would it be to spend five days researching the cause and severity of the mismatch while discussing solutions with the remote developer? There's 8 days. You decide to write a patch for the open source project shepherd it through the internal and external approval process, burning up another two weeks of time. 18 days. You finally get back and finish the original project, redoing a fair bit of work to account for the changes your patch introduced. 23 days. You're interrupted throughout this process several times by fires in production that need to be fixed RIGHT NOW. 28 days. Let's make the assumption your PM did their little trick, and slated 2 months for this project. Despite your own estimate being off (through no ill-will by anybody) by about 6x, your work is still completed before it's expected, and the teams depending upon your work are happy as clams. Even if it had finished in the original 5 days, everyone would be thrilled, and you'd get more work to do. From the PM's point of view, it's a win-win situation. From your point of view, the worst you have to endure is a twinge of "don't you trust me?", offset by the relief of not having to answer "why isn't it done yet" every day from day 6 on.
  - RealityVoid 9y ago
    Ideally, from my point of view, estimations should be not over nor under-estimated. They should be on point. Sure, on first glance, under-estimation leads to worse outcomes than oversetimation. But it will still lead to negative outcomes. Rational actors on the wrole chain will benefit and extract the most utility when they are as correct as possible. While your example showed how project implementation can creep up, I already knew that and my problem is more my inability to give accurate estimates and people's willingness to stretch their estimates by a lot. I KNOW some of you will not agree with me, but I think that giving 4x as long estimates will lead to developers spending more time on the actual implementation without noticeable improvements in the delivery. I know my natural tendency is to do so.
mjmahone17 9y ago
A PM is responsible for coordinating disparate groups of people. So if one person says “A will take 3 days” and someone else says “I can do B in 3 days, which I can’t start until A is done, and C in 2 days” what’s the correct time estimate for all the work? The first person will probably have issues they didn’t anticipate, so now their work is really 1 week long. The second will start on C, hopefully, then either spend a bit of time following up to see if they can start on B, or miss the fact that A is finished by a few days. So while people may be only a few days off per individual task, for a PM this has a multiplicative effect. So the PM can either act like an engineer and say “well there were X Y and Z unexpected things which is why this is going to take 3x as long” or just assume 4 “days of work” across 4-5 people really means 5 weeks before all the work is done (because not everyone can devote 100% to that work, some dependencies are difficult to hand off and can’t be done in parallel, etc).
mamcx 9y ago
Not, is very realistic if you deal with non-developers. You could deliver something in 1 hour, BUT, the customer/person that could answer you WHAT to do exactly will take days/weeks to be AVAILABLE. This is not a joke. For one of my very recent jobs, I need to wait 1 FULL YEAR TO MOVE ON. Then weeks after that. Despite already being paid in half! -- Developer time is NOT ONLY the time the developer smash the keyboard.

>4 days becomes 5 weeks Are you being serious? That only works if the people consuming these estimates don't have a clue and therefore can't call BS. This would get me aughed out of my job.

RealityVoid 9y ago

This also astounds me. I can't graps the art of these estimates. I suck at estimating deliviery times, and I'm a pretty good engineer. But I either over-estimate or under-estimate, I find it hard to be on point, there are always unexpected side effects. And I'm known as a sort of miracle worker, when they have something they can't solve, they come to me. But I HATE giving estimates. If I were to estimate things as suggested in this thread, it seems to me things would never get done. Ever. It simply boggles my mind people want and will fudge estimates on this scale.

falcolas 9y ago
Pretend, for a moment, that you're working on a one week project. You're estimating that week based on the ability to use an open source project which promises to take care of a large portion of the complexity for you. Also pretend you're new enough to not realize the hollowness of that promise. It's only three days in to the project that you realize there's a mismatch between what you need and what the project provides. You start a conversation with the project's lead developer; but they're only able to have half of any given conversation in a day. How hard would it be to spend five days researching the cause and severity of the mismatch while discussing solutions with the remote developer? There's 8 days. You decide to write a patch for the open source project shepherd it through the internal and external approval process, burning up another two weeks of time. 18 days. You finally get back and finish the original project, redoing a fair bit of work to account for the changes your patch introduced. 23 days. You're interrupted throughout this process several times by fires in production that need to be fixed RIGHT NOW. 28 days. Let's make the assumption your PM did their little trick, and slated 2 months for this project. Despite your own estimate being off (through no ill-will by anybody) by about 6x, your work is still completed before it's expected, and the teams depending upon your work are happy as clams. Even if it had finished in the original 5 days, everyone would be thrilled, and you'd get more work to do. From the PM's point of view, it's a win-win situation. From your point of view, the worst you have to endure is a twinge of "don't you trust me?", offset by the relief of not having to answer "why isn't it done yet" every day from day 6 on.
- RealityVoid 9y ago
  Ideally, from my point of view, estimations should be not over nor under-estimated. They should be on point. Sure, on first glance, under-estimation leads to worse outcomes than oversetimation. But it will still lead to negative outcomes. Rational actors on the wrole chain will benefit and extract the most utility when they are as correct as possible. While your example showed how project implementation can creep up, I already knew that and my problem is more my inability to give accurate estimates and people's willingness to stretch their estimates by a lot. I KNOW some of you will not agree with me, but I think that giving 4x as long estimates will lead to developers spending more time on the actual implementation without noticeable improvements in the delivery. I know my natural tendency is to do so.

mjmahone17 9y ago

A PM is responsible for coordinating disparate groups of people. So if one person says “A will take 3 days” and someone else says “I can do B in 3 days, which I can’t start until A is done, and C in 2 days” what’s the correct time estimate for all the work? The first person will probably have issues they didn’t anticipate, so now their work is really 1 week long. The second will start on C, hopefully, then either spend a bit of time following up to see if they can start on B, or miss the fact that A is finished by a few days. So while people may be only a few days off per individual task, for a PM this has a multiplicative effect. So the PM can either act like an engineer and say “well there were X Y and Z unexpected things which is why this is going to take 3x as long” or just assume 4 “days of work” across 4-5 people really means 5 weeks before all the work is done (because not everyone can devote 100% to that work, some dependencies are difficult to hand off and can’t be done in parallel, etc).

mamcx 9y ago

Not, is very realistic if you deal with non-developers. You could deliver something in 1 hour, BUT, the customer/person that could answer you WHAT to do exactly will take days/weeks to be AVAILABLE. This is not a joke. For one of my very recent jobs, I need to wait 1 FULL YEAR TO MOVE ON. Then weeks after that. Despite already being paid in half! -- Developer time is NOT ONLY the time the developer smash the keyboard.