> Software is built by groups of people who most defitely > cannot be modeled as mathematical entities. Putting aside whether mathematics is up to modeling

> 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.)