3 ms·

The problem with software estimates is making an estimate based off of the unknown for the first time. Somebody asks you to walk a certain route through a city

The problem with software estimates is making an estimate based off of the unknown for the first time. Somebody asks you to walk a certain route through a city and give them an estimate of how long it's going to take. This is the first time you've ever been asked to do this. The route has stop lights, paved walkways, thick forest where you have to trample your own path, crowded areas, construction, and all sorts of other characteristics. Think you're going to estimate that perfectly the first time? Nope. But guess what, you'll estimate it pretty well the next time you're asked to do the same route. Therein lies the problem with software and estimates. Many times what engineers are asked to estimate is an unknown or has portions of unknowns. Without having solved the problem prior to being asked it's going to be real tough to estimate it properly. Second time around, your estimate is going to be much much better. Most software is _not_ being asked to do something you've done once, twice or thirty times before. It's solving problems for the first time, estimates will be wrong.

lotyrin 11y ago
Yep. I like the idea of an agency or internal team that does the following: Come up with risk classes and complexity classes, with objective measure for what is or isn't in each class. ("Class X risk involves a library/technique/platform with we are not yet familiar."). Measure time spent on all tasks. Collect statistical distributions for each portion of the risk/complexity grid. Use those distributions and monte carlo simulation to estimate future projects to an appropriate degree of confidence (e.g. 95%). This probably means scheduling lots more time than you would have before, more than you will often need, use the rest for refactoring, training, completing unforeseen and therefore unestimated tasks (bug fixes?) maintaining the FOSS you are dependent on, etc.
jacques_chester 11y ago
Estimates are, by their nature, uncertain. The problem is less about uncertainty and more about having punishment or reward tied to them, implicitly or explicitly. Too often the first estimate turns into the plan. That's what makes us all so gunshy of estimation. That's not a problem with estimation, though.

lotyrin 11y ago

Yep. I like the idea of an agency or internal team that does the following: Come up with risk classes and complexity classes, with objective measure for what is or isn't in each class. ("Class X risk involves a library/technique/platform with we are not yet familiar."). Measure time spent on all tasks. Collect statistical distributions for each portion of the risk/complexity grid. Use those distributions and monte carlo simulation to estimate future projects to an appropriate degree of confidence (e.g. 95%). This probably means scheduling lots more time than you would have before, more than you will often need, use the rest for refactoring, training, completing unforeseen and therefore unestimated tasks (bug fixes?) maintaining the FOSS you are dependent on, etc.

jacques_chester 11y ago

Estimates are, by their nature, uncertain. The problem is less about uncertainty and more about having punishment or reward tied to them, implicitly or explicitly. Too often the first estimate turns into the plan. That's what makes us all so gunshy of estimation. That's not a problem with estimation, though.