The Case for Statistical Chaos Control in Software

Late last year, I was asked, “how do you define and measure chaos in software projects?” And, recently, I was struck by the parallels of not measuring for infection in the coronavirus outbreak in the US and not measuring for chaos in software. Just like the COVID-19, not measuring for the accumulation of chaos in software can result in reaching a tipping point of deadly systemic failure.

The significance of measuring for chaos becomes more apparent after contemplating the real-world consequences of systemically neglecting (not defining, not measuring) chaos in software projects.

Let’s consider a couple of examples of chaos in software from recent incidents: two airliners, full of passengers, running on autopilot, both taking unexpected nose-dives and striking the ground; or, cars full of people accelerating out-of-control resulting in fatal accidents. In both cases, there were warning signs; but, even in quality minded companies, engineering teams often don’t understand the practice of measuring and controlling chaos. Chaos in software is, of course, known to cause such events, and chaos in software projects, can- and does- prematurely end the life of products, companies and people. If we are neglecting to measure the presence of chaos in software, it’s only a matter of change-across-time until the product or service fails due to accumulated chaos reaching a critical mass.

My answer to the two initial questions can be found here:
https://iism.org/article/the-case-for-statistical-chaos-control-in-software-40

As illustrated in the article, statistical chaos control is easy to implement, and the benefits substantially outweigh the increase front-end effort — measurement for the win! Please have a read and let me know if you agree.