|Without "Never Events" |
a doctor is nothing more than a glorified butcher
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.
Until next time.