3 ms·

Estimation is a skill. You have to learn it and practice it. Estimation is not something you can just do. You have to be taught how. OA touched on this, for ma

Estimation is a skill. You have to learn it and practice it. Estimation is not something you can just do. You have to be taught how. OA touched on this, for many companies and types of projects the majority of development is doing things you do not understand and/or don't know how to do. Yet. You don't figure those things out until long after someone wanted an estimate and tonolan release date. It's not infrequent to have shipped v1 before you figure out how things work. Or needed to work. The quite "no plan survives contact with enemy" applies to softdev as "no design survives contact with production"

commandlinefan 8y ago
> estimation is a skill I've seen a lot of people suggest variations of this, but after 25 years, I still suck at it. Everybody I've ever worked with has sucked at it. Everybody I've ever even heard of has sucked at it. Maybe I've had a two-and-a-half decade of bad luck, but in 25 years I've encountered exactly two types of people: people who insist that "estimating is a skill and you have to develop your skill" but don't actually practice estimation, and people who suck at estimation.
- taeric 8y ago
  If you only gauge yourself on point estimates on something, then constantly being wrong doesn't help you build the skill. (Where point estimate is boiling it down to a single number.) Instead, try estimating several factors of it. Some as seemingly worthless as lines of code, new dependencies, old dependencies touched, use cases, etc. Odds are high that you can actually start estimating one of those with a bit better accuracy. Odds are also good that the one you can estimate well, happens to correlate well with time/cost. So, find what you can estimate, and then calculate a rough translation of that to what you are being asked. That make sense?

3 ms·

Estimation is a skill. You have to learn it and practice it. Estimation is not something you can just do. You have to be taught how. OA touched on this, for ma

by njharman 8y ago

commandlinefan 8y ago
> estimation is a skill I've seen a lot of people suggest variations of this, but after 25 years, I still suck at it. Everybody I've ever worked with has sucked at it. Everybody I've ever even heard of has sucked at it. Maybe I've had a two-and-a-half decade of bad luck, but in 25 years I've encountered exactly two types of people: people who insist that "estimating is a skill and you have to develop your skill" but don't actually practice estimation, and people who suck at estimation.
- taeric 8y ago
  If you only gauge yourself on point estimates on something, then constantly being wrong doesn't help you build the skill. (Where point estimate is boiling it down to a single number.) Instead, try estimating several factors of it. Some as seemingly worthless as lines of code, new dependencies, old dependencies touched, use cases, etc. Odds are high that you can actually start estimating one of those with a bit better accuracy. Odds are also good that the one you can estimate well, happens to correlate well with time/cost. So, find what you can estimate, and then calculate a rough translation of that to what you are being asked. That make sense?