What Are The “Never Events” for Software Quality?

Wednesday, February 25, 2009

ekg 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:

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. 

What “never events” can you think of? Remember: measureable, preventable, and serious.

Sergio Pereira Wednesday, February 25, 2009
* "Fixing" a bug without reproducing it first.
* Delete a test to make your code change pass
* Check in source code without getting latest first (hello VSS)
* Debug code that makes it all the way to Production.
* Mix data (potentially sensitive) of two different user sessions.
* Unintentionally making your application OSS by including an OSS module.
scott Wednesday, February 25, 2009
Deleting a test to make your code change pass should be criminal!
Mark Brackett Wednesday, February 25, 2009
Never events "cause serious injury or death to beneficiaries" - they're not prescriptive guidance on how to *avoid* that injury. Eg., tagging and counting surgical instruments before and after surgery would prevent "leaving a foreign object" - but the lack of counting is not a never event. It doesn't matter *how* you avoid amputating the wrong limb, just that you do (even if it's by dumb luck).

In that vein, not being able to retrieve source causes no immediate harm to the customer. Nor do manual changes to source, or debugging code in production.

I can only think of a few errors that I'd qualify as "never events":

- Corrupting or losing customer data
- Exploitable buffer overflow with high privs
- Crashing another app or the OS of the customer's machine
- Mucking with user controlled OS settings without explicit permission (Startup programs, adding to favorites or quick launch, etc.)
- Collecting data without explicit permission

All of these cause, IMHO, self evident "harm" to the consumer and are somewhat avoidable.
scott Wednesday, February 25, 2009
@Mark - good point.

I originally thought about listing events from the user's perspective. I didn't think it was specific enough. Saying "don't lose my data" is a bit like saying "don't let me die". Too vague to act on. In any case - those are all good ideas.
Scott Mitchell Saturday, February 28, 2009
This happened all the time at a colleague's place of employ (but should never happen): checking in code that has build errors (not usually done intentionally, but done b/c the person checking in the code didn't try building the solution before checking in).
Sergio Pereira Monday, March 2, 2009
@Mark, I guess I was seeing the program (not the user) as the patient. After all, we can only operate on the program.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!