What Are The “Never Events” for Software Quality?

Recent talk centered on software quality got me thinking of “never events”. The “never events” in health care are defined by the National Quality Forum to identity serious problems in the quality of a health care facility.  A “never event” has to be:

• Measureable
• Mostly preventable
• Have serious implications (like death or disability)

Here are some examples of these events from the list of 28 defined by the NQF:

• Surgery on the wrong body part
• Leaving a foreign object inside a patient
• Artificial insemination with the wrong sperm

These are not events that never occur, but events that should never occur. Humans will make mistakes, but a high quality hospital will have fewer occurrences of “never events” than a hospital with low standards.

I wonder if we could ever find consensus on a set of “never events” for software development. Perhaps we could start with the “Top 25 Most Dangerous Programming Mistakes”, except not all of these are preventable,  or at least easily preventable. Plus, the list is focused on dangerous programming mistakes. I’ve always felt that configuration management practices are a leading indicator of software quality, and a couple “never events” come to mind immediately: 

• A team should never find itself incapable of retrieving the exact source files used to produce a build of the software.
• A team should never find a build deployed with manual changes made outside of source control.