William Edwards Deming, the father of quality had a theory about the handling of defects. He wasn’t the originator of the theory, but he did put it in a fun way.

He defined the terms Common Cause and Special Cause.

Common Cause, also known as Natural Patterns, are historical, quantifiable variations to a system.

Special Cause or UnNatural Patterns are unpredictable occurrences in both frequency and severity.

So what does this mean? Common Cause, at least in Operations terms are those issues that occur regularly. For example, that error that comes up in the log all the time. The system that goes down every week. 

Special Cause on the other hand could be that power spike that caused the systems to go haywire. The computer that crashed due to hard drive failure etc.

So, how should you identify them? Is is where the Burnt Toast analogy comes in.

Say you have a job of making toast. The toast gets burnt and you scrape the burnt bits off with a knife. This keeps occurring, every slice of toast comes out burnt. So you scrape more and more.

You may decide to use a fork, at least that way you may not break the toast. Or, decide to cover up the burnt bits by slathering on butter. This is how Deming saw western manufacturing and how I see IT systems managed.

So, as a sane person, who had this job of producing toast, what would you do? Keep scraping? Build an auto scraper? I don’t know about you, but I would try to fix the toaster. This could be as simple as turning the heat setting down for a common cause. If your toast was working fine initially, and all of a sudden it started producing burnt toast, then it could be that your toaster is broken and you need a new toaster. This is a special cause. A variation that was unpredictable (e toaster breaking).

The system is consistently producing issues. Instead on focusing on fixing the end product, we should be focusing on the cause of the problem.  The toaster, yet in many it systems, we tend to focus on fixing issues in the aftermath, rather than in the root of the problem.

So how do we fix software issues are the root of the problem? This is where techniques such as Test Driven Development, Behaviour Driven Development etc come in. You fix defects before they become problems and start burning your toast.

If you decide to incorporate techniques such as Continuous Integration or Continuous Deployment before addressing the quality of the development before hand, what you are effectively doing is automatically burning your toast.