3 ms·

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

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.

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.