5 ms·

This is being a little extremist, no? I'm consistently asked to give estimates, and I mostly give estimates that are accurate within sane expectations. I think

This is being a little extremist, no? I'm consistently asked to give estimates, and I mostly give estimates that are accurate within sane expectations. I think what's missing here is that I can predict how long something is going to take when I talk with the managers/feature-planners about what the feature is. If I feel I have a solid understanding of the requirements, which pieces of code it'll touch, etc - then I can give a reasonable estimate. Now, the bigger the project the more difficult this becomes. Details I've missed is always a possibility, and that just stacks up the bigger the project is. So I think being specific in this type of discussion is really important. A feature that's going to take 6 months to implement is insanely tough to estimate, and very likely to have a wrong estimate. A feature that takes a week can pretty reliably be accurate within a day or two, in my experience. I'm not defending management in these sorts of things.. I think it's our job to not only give estimates, but include understanding about the expected validity of that estimate. All estimates are worth while though, your post makes it sound like they're not. You tell me you need a feature that's going to take 12+ months? It's so hard to predict that it's laughably wrong.. but that's still insanely useful. Why? Because now the management knows it's highly unlikely to be a 1 week, 1 month, w/e feature. It's big.

Aaargh20318 8y ago
> I think what's missing here is that I can predict how long something is going to take when I talk with the managers/feature-planners about what the feature is. If I feel I have a solid understanding of the requirements, which pieces of code it'll touch, etc - then I can give a reasonable estimate. I'd argue you can't. Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on it all day by now. Not because the feature is that difficult, or because I didn't get a set of good requirements. The requirements are crystal clear and should be easy to implement. The reason it's taking so long is that I'm fighting with a UI component that doesn't behave as expected (or documented). What should have been a trivial part of this task, a matter of seconds and not worth estimating at all, turns out to take all day because I didn't know this specific component is misbehaving and I couldn't have known until I started implementing it. You cannot predict things like that without doing it.
- chiefalchemist 8y ago
  Oh. I feel your pain. But to clarify: You can't predict things well that you haven't done before. The point being, when trying to predict an unknown it's best to give a range and not a fixed estimate. If possible.
  - jrs235 8y ago
    And then management only hears the low number of the range.
    - jacques_chester 8y ago
      "Will management abuse the estimation process?" is a different question from "is estimation possible and improvable?"
    - chrisbennet 8y ago
      I like to use the range: “2 weeks to 2 years - roughly.”
- notheguyouthink 8y ago
  > Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on it all day by now. Not because the feature is that difficult, or because I didn't get a set of good requirements. The requirements are crystal clear and should be easy to implement. Just because you're wrong sometimes doesn't mean you can't be right more often than not. Another way to look at it is, as a company how can you budget anything if you can't make even the slightest of estimations? What you're suggesting results in throwing away any ability to budget, roadmap, coordinate, etcetc. Absolute prediction is of course impossible, but if what you're saying is true than I should buy a lottery ticket because my estimations are insanely lucky. And sure, I get estimations that run long, we all do - I'm not saying otherwise.
  - cabalspecter 8y ago
    This is for me the dissonance between agile methodologies and reality. Agile methodologies assume having a flexible scope and time due to the project unknowns (technical, business, social, etc.). But usually budgeting in the real world is required to follow: I promise to deliver X scope that’s going to cost Y dollars in Z time.

Aaargh20318 8y ago

> I think what's missing here is that I can predict how long something is going to take when I talk with the managers/feature-planners about what the feature is. If I feel I have a solid understanding of the requirements, which pieces of code it'll touch, etc - then I can give a reasonable estimate. I'd argue you can't. Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on it all day by now. Not because the feature is that difficult, or because I didn't get a set of good requirements. The requirements are crystal clear and should be easy to implement. The reason it's taking so long is that I'm fighting with a UI component that doesn't behave as expected (or documented). What should have been a trivial part of this task, a matter of seconds and not worth estimating at all, turns out to take all day because I didn't know this specific component is misbehaving and I couldn't have known until I started implementing it. You cannot predict things like that without doing it.

chiefalchemist 8y ago
Oh. I feel your pain. But to clarify: You can't predict things well that you haven't done before. The point being, when trying to predict an unknown it's best to give a range and not a fixed estimate. If possible.
- jrs235 8y ago
  And then management only hears the low number of the range.
  - jacques_chester 8y ago
    "Will management abuse the estimation process?" is a different question from "is estimation possible and improvable?"
  - chrisbennet 8y ago
    I like to use the range: “2 weeks to 2 years - roughly.”
notheguyouthink 8y ago
> Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on it all day by now. Not because the feature is that difficult, or because I didn't get a set of good requirements. The requirements are crystal clear and should be easy to implement. Just because you're wrong sometimes doesn't mean you can't be right more often than not. Another way to look at it is, as a company how can you budget anything if you can't make even the slightest of estimations? What you're suggesting results in throwing away any ability to budget, roadmap, coordinate, etcetc. Absolute prediction is of course impossible, but if what you're saying is true than I should buy a lottery ticket because my estimations are insanely lucky. And sure, I get estimations that run long, we all do - I'm not saying otherwise.
- cabalspecter 8y ago
  This is for me the dissonance between agile methodologies and reality. Agile methodologies assume having a flexible scope and time due to the project unknowns (technical, business, social, etc.). But usually budgeting in the real world is required to follow: I promise to deliver X scope that’s going to cost Y dollars in Z time.