CHAOS = BS

Anyone who has looked at software development methods, myself included, is probably familiar with the CHAOS report of The Standish Group. I have blogged before about Robert Glass's article that the numbers reported that group simply are not supported by other studies. I was happy to see that referenced on Herding Cats.

The effects of the data they report (189% cost overrun average) are negative for the IT industry. They are used to justify all means of odd process controls and contribute to a general excessive scepticism about the possibility of making a software project a success. The lack of context given for the data (actually, the data is kept secret) means that all of this is based on a very shaky quantitative foundation.

Having just finished "Fooled by Randomness", I am going to take another look at the Monte Carlo approach to estimation. I used it in a couple of cases to provide broad estimates for large projects, but all of the numbers came out quite low. I still the think the only responsible thing to do is to provide a range of estimates, especially when the nature of the work to be done is uncertain. And it usually is. The real benefit of the simulation approach, from the fooled by randomness perspective, is that they allow to take account of the black swans. If you are using a purely inductive approach, you can't account for things that have never happened. Like a 3 day power outage in your server room. Or system administrator that changes the name of your source control server and costs 10 person days of work. Or a new programmer that checks his whole c drive into the source code repository. Well, those 3 have actually happened to me, but they aren't the sort of thing I usually factor into my estimates, particularly when using the methods from "Planning Extreme Programming", which are purely based on yesterday's weather.

The real challenge here is estimating the shifting sands. Until you have a feel for the rate at which requirements change, you are only going to be able to estimate based upon what people thought they might want something they don't understand to do. Of course, if there is a reorganization in a business you are supporting, and there usually is at some point, the rate of change can shoot up. This is where the difference between methods really starts to kick in. If you are using a method that "embraces change" (the subtitle of the XP book), then you can leverage change to be the engine that carries the organization forward. If you try to keep the requirements frozen, you will be one of the projects reported when the Standish Group calls and says, "tell me about your failed projects".