4 ms·

> 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

by 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.
laaph 8y ago
I'm trying to get an app to the app store. Mysteriously, the archive button on XCode isn't working. It says it compiles successfully and yet there is no archive to submit when I'm done. I've googled all over and everyone else has a different solution to this problem. This little issue has delayed release a day so far. I've done this 50 times before (10 times in this project!) and these kinds of issues still occasionally occur. How does anyone predict for this kind of thing?

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.

laaph 8y ago

I'm trying to get an app to the app store. Mysteriously, the archive button on XCode isn't working. It says it compiles successfully and yet there is no archive to submit when I'm done. I've googled all over and everyone else has a different solution to this problem. This little issue has delayed release a day so far. I've done this 50 times before (10 times in this project!) and these kinds of issues still occasionally occur. How does anyone predict for this kind of thing?