"Never Events" in Software Development

Without "Never Events"
a doctor is nothing more than a glorified butcher

There is a phrase in the medical profession known as a “never event.”  It is something that should never happen in a hospital or another medical setting.  People have been practicing medicine since Neolithic times.  We have only been writing software for about seventy years.  I think we can learn a few things from the field of medicine and I would like to discuss it on this week’s blog.

The term “never event” came from a medical paper from the National Quality Forum.  These are mistakes which should never happen in any medical setting.  Some examples of these never events are, people receiving the wrong type of blood during a transfusion, surgeons amputating the wrong limb, and discharging an infant to the wrong set of parents.  If something like this happens, the doctor is subject to profound liability, and a patient could die.  It is why they are called “never events.”

I thought about this, and I felt that those of us in the software business should have a series of “never events” for our profession.  If we are going to improve in the agile community, we need to have a set of standards and those standards should include things which should never happen.

Here is my list of never events for software development –

• Code which exists in production should never reside on individual’s computer; it should all reside in source control.
• The database administrator should never ignore system backups of data; data should be backed up regularly and before scripts are applied to the system.
• All code which performs business logic should have unit tests; this way you will understand where the system has changed and what the possible changes are.
• Network servers should receive regular patches and security upgrades; this will discourage hackers and avoid technical debt.
• A developer should never work longer than 10 hours; fatigue causes mistakes.
• Before checking in the code, it should be code reviewed by another developer; an extra set of eyes on the code prevents errors and helps to learn.

Those are my starting points for “never events” in software.  Look forward to what each of you thinks should be included on this list.

Until next time.