What Are The “Never Events” for Software Quality?

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.

Print | posted @ Wednesday, February 25, 2009 5:48 AM

Comments on this entry:

Gravatar # re: What Are The “Never Events” for Software Quality?
by Sergio Pereira at 2/25/2009 1:20 PM

* "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.
  
Gravatar # re: What Are The “Never Events” for Software Quality?
by scott at 2/25/2009 4:09 PM

Deleting a test to make your code change pass should be criminal!
  
Gravatar # re: What Are The “Never Events” for Software Quality?
by Mark Brackett at 2/25/2009 5:20 PM

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.
  
Gravatar # re: What Are The “Never Events” for Software Quality?
by scott at 2/25/2009 7:24 PM

@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.
  
Gravatar # re: What Are The “Never Events” for Software Quality?
by Scott Mitchell at 2/28/2009 1:05 AM

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).
  
Gravatar # re: What Are The “Never Events” for Software Quality?
by Sergio Pereira at 3/2/2009 2:54 PM

@Mark, I guess I was seeing the program (not the user) as the patient. After all, we can only operate on the program.
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 7 and 7 and type the answer here: