3 ms·
> "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 weath
by 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.)