3 ms·

This is a nice taxonomy of estimation games, but stopping the games won't address the root problem: Software development is complex enough to be fundamentally u

This is a nice taxonomy of estimation games, but stopping the games won't address the root problem: Software development is complex enough to be fundamentally unpredictable. The games are just about hedging against people not wanting to hear that.

tempodox 12y ago
I think you're painting it a bit too black. Having both sides agree to the fact that it's an estimate (and not an exact prediction) does help. And if you make the client understand the contingencies and unknown factors, you may get around the expectation to make an accurate prediction — which nobody can give anyway, except when doing the same thing the umpteenth time. Communicating often on progress that you actually do make can still give the client a good sense of confidence and control on what's happening.
jt2190 12y ago
> Software development is complex enough to be > fundamentally unpredictable. This is false. The weather is an extremely complex system, yet we use weather forecasts all the time. What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future. ("Maybe I'll carry an umbrella today.") The equities market is an extremely complex system, yet we use market forecasts all the time. What's different between equities market and software is that everyone knows that equities market is extremely complex, and we account for that when we think about the price of an equity in the future. ("Maybe I'll diversify my investments.") Forecasting the completion date of a software project is no more complex[1] than predicting the weather or the future price of an equity. In no way is it "fundamentally unpredictable." What's different is that people don't regard project estimates as, well, _estimates_. [1] It's probably a lot simpler.
- john_b 12y ago
  > "What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future." Weather is governed by impersonal physical forces which can be described by mathematics. Software is built by groups of people who most defitely cannot be modeled as mathematical entities. Weather is a bad analogy here. > "The equities market is an extremely complex system, yet we use market forecasts all the time. What's different between equities market and software is that everyone knows that equities market is extremely complex, and we account for that when we think about the price of an equity in the future. ("Maybe I'll diversify my investments.")" Those market foreasts are often wrong. Even a company's own forecasts are frequently wrong, despite having the optimal perspective from which to make those forecasts. Furthermore, diversifying investments is easy to do because the price mechanism makes those investments fungible (in a liquid market, anyway). This is not the case with software. Each piece of software is unique. You may "diversify" your software by investing in multiple projects, but ultimately you have a business need for a piece of software which does task X. "Diversifying" by funding software that does tasks Y and Z will not help you if the software "investment" in task X fails. "Diversifying" in three software projects, all intended to do task X, will roughly triple your costs for doing X. Again, equities are a bad analogy. Software development is a process which can't be easily summarized by analogies to existing systems. In fact, the term "software development" can describe many different systems. The real reason schedule estimation in software development is so hard is because, regardless of which system of software development is used, the problem of simultaneously optimizing to maximise a desired quality while minimizing the cost/schedule is inherently hard in a mathematical sense. Changes which promote one oppose the other, and the sensitivity of a software development system to unknown and unpredictable future changes cannot, obviously, be predicted in advance. Your point about hedging one's bets is valid, but there are costs to doing so which are not as simple as carrying an umbrella or splitting up a pile of money across multiple equities.
  - jt2190 12y ago
    > Software is built by groups of people who most defitely > cannot be modeled as mathematical entities. Putting aside whether mathematics is up to modeling human behavior, why does a project schedule estimate need to be modeled using people? > Weather is a bad analogy here. I was using weather as an example of complex things that can be estimated, not as an analogy for software development itself. Sorry if I wasn't clear about this. > Those market forecasts are often wrong. Useful forecasts/estimates are seldom binary, and "wrong" versus "right" is a bad way to evaluate their usefulness. Estimates have both precision and accuracy. For example if you want perfect precision (as in the wrong/right example), you may in turn get a very low accuracy, i.e. the estimate will often be incorrect. If, on the other hand, you can live with less precision, you can often get higher accuracy. > The real reason schedule estimation in software > development is so hard is because, regardless of which > system of software development is used, the problem of > simultaneously optimizing to maximise a desired quality > while minimizing the cost/schedule is inherently hard in > a mathematical sense. Changes which promote one oppose > the other, and the sensitivity of a software development > system to unknown and unpredictable future changes > cannot, obviously, be predicted in advance. Again, this is true only if you need very high precision and very high accuracy. If you can live with lower accuracy and precision, estimation becomes quicker, easier and cheaper. So I stand by my original assertion that software estimation is not impossible. (edit: To remain consistent, I should say that software schedules are certainly predictable, just not perfectly predictable. Most teams can get by just fine with good enough predictions.)

tempodox 12y ago

I think you're painting it a bit too black. Having both sides agree to the fact that it's an estimate (and not an exact prediction) does help. And if you make the client understand the contingencies and unknown factors, you may get around the expectation to make an accurate prediction — which nobody can give anyway, except when doing the same thing the umpteenth time. Communicating often on progress that you actually do make can still give the client a good sense of confidence and control on what's happening.

jt2190 12y ago

> Software development is complex enough to be > fundamentally unpredictable. This is false. The weather is an extremely complex system, yet we use weather forecasts all the time. What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future. ("Maybe I'll carry an umbrella today.") The equities market is an extremely complex system, yet we use market forecasts all the time. What's different between equities market and software is that everyone knows that equities market is extremely complex, and we account for that when we think about the price of an equity in the future. ("Maybe I'll diversify my investments.") Forecasting the completion date of a software project is no more complex[1] than predicting the weather or the future price of an equity. In no way is it "fundamentally unpredictable." What's different is that people don't regard project estimates as, well, _estimates_. [1] It's probably a lot simpler.

john_b 12y ago
> "What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future." Weather is governed by impersonal physical forces which can be described by mathematics. Software is built by groups of people who most defitely cannot be modeled as mathematical entities. Weather is a bad analogy here. > "The equities market is an extremely complex system, yet we use market forecasts all the time. What's different between equities market and software is that everyone knows that equities market is extremely complex, and we account for that when we think about the price of an equity in the future. ("Maybe I'll diversify my investments.")" Those market foreasts are often wrong. Even a company's own forecasts are frequently wrong, despite having the optimal perspective from which to make those forecasts. Furthermore, diversifying investments is easy to do because the price mechanism makes those investments fungible (in a liquid market, anyway). This is not the case with software. Each piece of software is unique. You may "diversify" your software by investing in multiple projects, but ultimately you have a business need for a piece of software which does task X. "Diversifying" by funding software that does tasks Y and Z will not help you if the software "investment" in task X fails. "Diversifying" in three software projects, all intended to do task X, will roughly triple your costs for doing X. Again, equities are a bad analogy. Software development is a process which can't be easily summarized by analogies to existing systems. In fact, the term "software development" can describe many different systems. The real reason schedule estimation in software development is so hard is because, regardless of which system of software development is used, the problem of simultaneously optimizing to maximise a desired quality while minimizing the cost/schedule is inherently hard in a mathematical sense. Changes which promote one oppose the other, and the sensitivity of a software development system to unknown and unpredictable future changes cannot, obviously, be predicted in advance. Your point about hedging one's bets is valid, but there are costs to doing so which are not as simple as carrying an umbrella or splitting up a pile of money across multiple equities.
- jt2190 12y ago
  > Software is built by groups of people who most defitely > cannot be modeled as mathematical entities. Putting aside whether mathematics is up to modeling human behavior, why does a project schedule estimate need to be modeled using people? > Weather is a bad analogy here. I was using weather as an example of complex things that can be estimated, not as an analogy for software development itself. Sorry if I wasn't clear about this. > Those market forecasts are often wrong. Useful forecasts/estimates are seldom binary, and "wrong" versus "right" is a bad way to evaluate their usefulness. Estimates have both precision and accuracy. For example if you want perfect precision (as in the wrong/right example), you may in turn get a very low accuracy, i.e. the estimate will often be incorrect. If, on the other hand, you can live with less precision, you can often get higher accuracy. > The real reason schedule estimation in software > development is so hard is because, regardless of which > system of software development is used, the problem of > simultaneously optimizing to maximise a desired quality > while minimizing the cost/schedule is inherently hard in > a mathematical sense. Changes which promote one oppose > the other, and the sensitivity of a software development > system to unknown and unpredictable future changes > cannot, obviously, be predicted in advance. Again, this is true only if you need very high precision and very high accuracy. If you can live with lower accuracy and precision, estimation becomes quicker, easier and cheaper. So I stand by my original assertion that software estimation is not impossible. (edit: To remain consistent, I should say that software schedules are certainly predictable, just not perfectly predictable. Most teams can get by just fine with good enough predictions.)