Writing Safety Critical Software

I first started using and mentoring developers on agile software development techniques like eXtreme Programming (XP) and Scrum over a decade ago. Often called “lightweight” methodologies, agile software development lifecycles have been generally misunderstood as lacking enough rigor and sophistication to be used in safety-critical systems. Many have erroneously assumed that Agile, Scrum, and related methodologies can’t really be implemented in risk-focused “important” industries like medical devices because they believe only classic waterfall will be accepted by the FDA.

Recently I ran across a great presentation by the folks at Pathfinder Software entitled “Agile Development for FDA Regulated Medical Software.” Pathfinder’s engineers help explain why the FDA doesn’t know or really care about what software methodology you use as long as you ensure that the output of your development approach results in high quality, safe, reliable software. The explanation that Michael and Tavi from Pathfinder gave about “formal” versus “casual” is quite effective and it reminded me about how often I’ve had to give the same lecture. I’ve been involved in the development of Class I/II/III devices since 1995 and I’ve had to clarify confusion about the use of agile and non-waterfall software development methodologies in almost all of my projects. The confusion has only increased with the introduction of MDDS and the proliferation of mHealth and modern mobile software performing roles traditionally performed by dedicated medical devices.

The FDA’s 21 CFR Part 820 Quality System Regulations (QSR) and the numerous other regulations that derive from it (in both the USA and other countries that follow the FDA) does dictate quite a bit but detailed software development approaches are neither described nor prescribed in the QSR. Waterfall, one of the original plan-driven methodologies, became the standard not because the FDA prescribed it but because that was the norm in the latter half of the 20^th century when developing extensible software was expensive and time consuming. It was a time when hardware and software were tied together and programming languages, frameworks, components, and platforms offered little forgiveness when requirements changed. This was world in which everything was custom – from purpose-built operating systems written for specific devices as well all other software components needed by a medical device. Back then it was believed that unless you wrote everything yourself you couldn’t test and depend on the code.

Much of that changed in the 90’s and then upended even further in the early part of the 21^st century; we should no longer weighed down by the baggage of the past.These days even our hardware is agile and extensible, real-time operating systems are plentiful, software platforms are malleable, mHealth is well established, and programming languages are sophisticated so we need to be open to reconsidering our development approaches, especially risk-based agile.

Why should we use “risk-based” agile? Because not every single line of code in software can or should be treated equally – some parts of our medical device software can kill people, many parts merely annoy people, but most other parts simply aren’t worth the same attention as the safety-critical components. When you treat every line of code the same (as is often true in a plan-driven approach) and you have a finite amount of resources and time you end up with lower quality software and less reliable medical devices. It’s not fair to blame the FDA for our own bad practices.

Our focus in safety-critical systems is high reliability with a short time to market and excellent functionality that meets ever increasing sophistication of design. In an age when even NASA uses agile techniques to get spacecraft reliably into orbits of planets millions of miles from earth, we need to recognize that agile has a place in medical device and FDA regulated environments.