Why Software Defects Kill

TL;DR

Software and firmware defects account for 12 Class I (critical) medical device recalls, the highest of any failure category. When a software defect causes a Class I recall, patients are at risk of death or serious harm. The standard explanation is “inadequate testing” or “poor validation.” The deeper explanation is planning fallacy: every engineering team consistently underestimates complexity, overestimates their timeline, and ships software that hasn’t been adequately validated because the schedule wouldn’t allow it. The fix is a different objective function.

The Pattern

If you look at the FDA’s device enforcement data, software and firmware defects are not the most common failure category. They account for 10.4% of all enforcement actions, behind sterility/packaging (28.2%) and component failures (16%).

But software defects account for 12 Class I recalls, the highest of any category.

Class I recalls are the FDA’s most severe classification. They represent situations where use of the device could cause serious adverse health consequences or death. When a software defect triggers a Class I recall, patients are in immediate danger.

Category	Class I Recalls
Software & Firmware Defects	12
Sterility & Packaging Integrity	8
Component & Assembly Failure	6
Material & Component Failure	5
Process Control & Validation	4

The stakes for software defects are lethal. A ventilator alarm that fails to sound. A defibrillator that delivers the wrong energy. An insulin pump that miscalculates dosage. These are not packaging errors. They are software bugs that kill.

A Composite Case

To illustrate the method, we built a composite case from three real companies that received Class I recalls for software defects. We’ve blended their data and removed identifying details. The patterns, citations, and timeline are real. The company name is not.

The company: A mid-size medical device manufacturer (~150-300 employees) producing a software-intensive therapeutic device. The product requires embedded firmware, real-time control algorithms, and rigorous regulatory validation under 21 CFR Part 820 and IEC 62304.

The recall: A software defect was discovered in the device’s control algorithm. The defect could cause the device to fail to deliver therapy, or to deliver therapy incorrectly. The company issued a Class I recall affecting thousands of units in the field.

The timeline: The software was developed on a compressed schedule. Validation testing was planned for 12 weeks but executed in 8. Several test cases were marked “deferred” to meet the launch date. The defect was discovered three months after launch through a field complaint. The recall was initiated within 30 days.

By the time the recall was public, the engineering team had known about the compressed validation schedule for at least six months. The deferred test cases were documented. The risk was known. The schedule won.

The question is: why did the schedule win?

The Surface Diagnosis

The regulatory consultant’s answer: strengthen your software validation process.

The prescription is typically procedural: more rigorous test coverage, better traceability matrices, additional review gates, more automated testing. The company implements the recommendations. The next software release still ships with compressed validation. The same pattern repeats.

The problem is that the prescription is incomplete. It addresses the mechanism without addressing the motive. It addresses the mechanism without addressing the motive.

The Deep Diagnosis

Software defects in medical devices exist because of planning fallacy, a cognitive bias that was adaptive for most of human evolutionary history but is destructive in modern software engineering.

Here’s the chain:

Step 1: The project is scoped. The engineering team estimates the development timeline. The estimate is optimistic. This is not dishonesty, it’s planning fallacy. Every team believes their project will go smoothly. Decades of research show that even experts consistently underestimate software complexity by 40-60%.

Step 2: The schedule is set. Management accepts the optimistic estimate. The launch date is set. Investors, regulators, and customers are told when the product will ship. The schedule becomes a commitment, not a plan.

Step 3: Development begins. The team encounters the expected problems: integration issues, algorithm bugs, hardware-software interface problems, regulatory requirements that weren’t fully understood at scoping time. The work takes longer than estimated.

Step 4: The schedule conflicts with quality. Validation testing is the first thing to be compressed. Why? Because validation doesn’t “add features”, it verifies that the features work. In a schedule conflict, validation is the easiest thing to defer. The team tells themselves they’ll catch the defects in field monitoring. They’ll patch the software after launch. The schedule wins.

Step 5: The defect ships. The software is released with incomplete validation. The deferred test cases are never executed. The defect that would have been caught in validation reaches patients. The Class I recall is initiated.

The software defect is a failure of planning. The team planned for the best case, and the best case didn’t happen. The schedule was set on an optimistic estimate, and the schedule drove every decision after that.

Why Naming Names Doesn’t Help

This article uses a composite case rather than naming a specific company. This is a deliberate choice, not a legal precaution.

Logically, naming a company and analyzing its software failures treats the symptom as if it were the cause. Company X had a software defect. So what? Every company that ships software has defects. The useful unit of analysis is the pattern, not the company.

Tactically, public shaming triggers defensiveness, not introspection. The engineering team that shipped a defective product is already under pressure. Public criticism makes them double down on protecting their reputation, not examining their planning process. The company that might have been receptive to help becomes hostile to it.

We’ve seen this dynamic play out repeatedly. Companies that experience software recalls fall into two categories: those that use the experience to improve their planning and validation processes, and those that treat it as a reputational crisis to be managed. The difference is whether the leadership team can see past defensiveness to the real constraint.

Our job is to help companies see that constraint. Public shaming makes that harder, not easier.

The TOC Diagnosis

Theory of Constraints frames this differently. Instead of asking “what testing processes are broken?” it asks “what is the system constraint that makes compressed validation the rational choice?”

In most medical device companies, the constraint is time-to-revenue, the rate at which the organization can move from concept to approved, shipped, billed product. Everything in the organization is optimized to maximize this throughput.

Planning fallacy emerges as a rational response to this constraint. Here’s why:

Optimistic estimates win funding. The project with the most aggressive timeline is the one that gets approved. Pessimistic estimates are rejected or pressured. The planning fallacy is rewarded by the funding process.
The schedule is a commitment, not a plan. Once the launch date is set, it becomes a promise to investors, regulators, and customers. Changing the date is costly. Compressing validation is cheaper than delaying the launch.
Local optimization reinforces the dynamic. The engineering team optimizes for feature completion (their metric). The quality team optimizes for test coverage (their metric). Neither team optimizes for the system constraint (time-to-revenue), because neither team has visibility into it. Compressed validation is the equilibrium that emerges when local optimizations conflict.

The TOC prescription is counterintuitive: don’t add more testing. Fix the planning process.

When the constraint is time-to-revenue, every estimate in the organization should include a buffer for uncertainty. Not a management reserve, a built-in acknowledgment that software complexity is inherently unpredictable.

If the validation timeline is compressed to meet a launch date, the launch date should be adjusted, not the validation.
If the planning process rewards optimistic estimates, it should be changed to reward realistic ones.
If the quality team is siloed from engineering, the dependency chain is broken and the constraint can’t be seen.

The software defect doesn’t need more testing. It needs better planning.

What This Looks Like in Practice

Here’s what the pattern looks like when it’s working:

The TOC diagnosis reveals the constraint: the engineering team is measured on on-time delivery. Every validation finding that threatens the schedule is deprioritized. The quality team learns this, so they focus on procedural compliance rather than rigorous testing. The validation process produces documentation but no insight.

The fix is a conversation between the CEO, VP Engineering, and VP Quality that realigns the engineering metrics to include regulatory risk. Once the engineering team is measured on both schedule and software quality, the dynamic changes. Validation findings start being raised and addressed. The validation process starts producing insight. The next software release ships with adequate testing, and the team sleeps better.

The procedures didn’t change. The objective function did.

We haven’t yet run this diagnosis with a medical device software client. The pattern comes from analyzing the FDA data and mapping it to the cognitive drivers we see repeatedly in software organizations. The medical device space is where the pattern is most visible, because the consequences of getting it wrong are public, documented, and potentially lethal. That’s why we’re starting here.

The Method

If you’re reading this and recognizing your own organization, here’s what to do:

1. Map the validation chain. Trace a single software defect from introduction to detection. At each stage, ask: was this defect caught by the validation process? If not, why? Was the test case deferred? Was the schedule compressed?

2. Identify the constraint. What metric is the engineering team actually optimizing for? Is it feature completion? Schedule adherence? Bug count? The constraint is the metric that everyone is implicitly optimizing for, even when it conflicts with quality.

3. Realign the objective function. The engineering team needs to be measured on software quality, not just schedule. This means including validation completeness and defect escape rate in the engineering metrics. This is a leadership decision, not a quality decision.

4. Introduce planning buffers. Every software estimate should include a buffer for uncertainty. Not a management reserve, a built-in acknowledgment that complexity is unpredictable. The buffer should be visible, not hidden.

5. Test the fix. Run a single software release through the new process. Does validation produce insight or documentation? If it produces insight, the objective function has shifted. If it produces documentation, you haven’t changed the constraint.

A Note on the Data

The composite case in this article is built from three real FDA Class I recalls for software defects. The companies produce software-intensive therapeutic devices requiring embedded firmware and real-time control algorithms. The citations, timeline, and patterns are accurate. The company name and identifying details are fictional.

We chose this approach because the useful unit of analysis is the pattern, not the company. If you’re going through a similar situation, the analysis applies to you regardless of whether your name appears in an article. If you’re not, the analysis helps you understand the patterns to watch for before they become recalls.

Either way, the goal is the same: help organizations see their constraints clearly enough to address them.

This article is part of a series on cognitive drivers of medical device quality failures. The introductory article, “The Same Seven Mistakes, Every Company, Every Decade,” provides the broader framework. The full pattern library and underlying data are available for review.