When Quality is Personal

Recently my friend and colleague Israel Gat wrote a blog Quality is Personal, about how people have different contexts from which to view quality. Israel says I gave him the idea during a presentation. My thoughts on personal quality come from Jerry Weinberg’s 4-volume series on quality management written in the 1990s where he states, “Quality is value to some person.”

I’ve recently had an experience that got me to thinking about software quality—in a very personal context. After experiencing some dizzy spells and a black out a few weeks ago, I ended up in the hospital getting a pacemaker implanted. It’s a little piece of hardware—about 50 cent piece size (but thicker)—with lots of software. As the cardiologist explained in very technical language, “The heart has two major systems—plumbing and electrical—your issues were with the electrical system.” The pacemaker software analyzes signals from the two halves of the heart and then generates a signal to activate the right muscles.

I would definitely call this a case of “mission critical” software, since it’s pretty critical to me. Quality isn’t abstract when you are dependent on it correctly analyzing electrical signals in your heart and zapping a signal to the atria or ventricles when needed. Having seen how software is built in many organizations over the last few decades, it’s a little disconcerting. However, I also know that makers of implantable medical devices are careful, thorough, and regulated (regulations I’m actually happy about).

As part of checking out my pacemaker, the tech hooks it up to their computer and in one of the tests, runs my heart rate up and down (whoo-whee). It got me to thinking that I really wanted their software testing to be first rate! No accidental running heart rate up and down wanted!

There is a difference between kinds of software. The phrase “fit-for-use” means that quality for gaming software, a payroll application, a Shuttle spacecraft system, an iPod app, and pacemaker software will surely be different. However, no matter the application, I want to see adequate testing (preferably automated), refactoring to keep technical debt down, good user-driven acceptance testing, sound feature requirements and showcasing (Hmm, would I want to be the test-bed for pacemaker software acceptance testing? Not). I don’t want my mission critical software developed using one of Ed Yourdon’s Death March projects, nor released early to meet some executive’s wish-based project plan.

When I’ve thought about medical device software in the past, it’s always been in the abstract—it was always someone else’s life or limbs at stake. When it’s your own you take a very different view. There are always trade-offs—I’m looking for excellence, not perfection—but those of us who are building software, for whatever purpose, should stop and think for a time about what if this was my paycheck, or my air-traffic control system, or my critical business decision, or my heart. Maybe we’d have more emphasis on quality and software excellence than we do today.

    Comments

    1. I have a much traveled friend who is in the transportation business. In a recent executive workshop I held with him and his staff I contrasted the quality required of software handling seat assignment versus the the quality required for determining the amount of fuel a plane needs to carry given weather conditions. My friend jumped from his chair and half jokingly exclaimed: “Israel, you got it all wrong – quality of seat assignment software is far more important to me. Just think what being seated in a middle seat means to me!”

      As I myself am much traveled, I must admit there is some merit to his point…

      Israel