At a client site in Sacramento, CA off and on since last December. Driving back to hotel tonight, there was a radio show on the current Uniform California Earthquake Rupture Forecast (Version 3).

A former Colorado neighbor is an earthquake researcher and we've had discussions about probabilistic estimation of complex systems and complexity sciences

The notion that we can't predict - to some level of confidence - outcomes in the future is of course simply not correct. Earthquake prediction is not technically possible in the populist sense. It's a complex probabilistic process.

Making forecasts - estimates of *future *outcomes - for software development projects is much less complex. The processes used to make these estimates range from past performance time series to multi-dimensional parametric models. Several tools are available for these parametric model. Steve McConnell provided an original one I use a decade or so ago. Steve provides some background on making estimates where he speaks of the 10 deadly sins

- Confusing targets with estimates - the bug-a-boo of all #NoEstimates advocates. It's simple - DON'T DO THIS.
- Saying yes when you mean no - no quantitative data and guessing mans bad estimates - DON'T DO THIS
- Committing Too Early - use cone of uncertainty
- Assume underestimating has no impact on project - DON'T DO THIS
- Estimating in the Impossible Zone - an optimistic estimate has a non-zero probability of coming true
- Overestimating from use of new tools - DON'T DO THIS
- Using only one estimating technique - DON'T DO THIS
- Not using estimating software - DON'T DO THIS
- Not including risk factors - the the primary sin of the simple small samples of stories or story points used to linearly forecast future performance. DON'T DO THIS.
- Providing
*off the cuff*estimates - this is called guessing. DON'T DO THIS*.*

When you need to estimate - as you do in any non-trivial project - make sure you're not committing any of the 10 sins Steve mentions.

**So Why The Earthquakes and SW Estimates?**

One process is very complex and emerging science. One is a well developed mathematical process.

There is so much misinformation about estimating software development, it's hard to know where to start. From outright *wrong math, *to misuse of mathematical concepts, to failure to acknowledge that estimates aren't for developers, they're for those paying the developers.