Why Software Keeps Failing is the title of the editor’s page for IEEE’s Spectrum December 2025 issue.
The answer to “why software keeps failing”?
Lessons are learned but not applied.
From the editor:
In 2005’s “Why Software Fails,” in IEEE Spectrum, a seminal article documenting the causes behind large-scale software failures, Charette noted, “The biggest tragedy is that software failure is for the most part predictable and avoidable. Unfortunately, most organizations don’t see preventing failure as an urgent matter, even though that view risks harming the organization and maybe even destroying it. Understanding why this attitude persists is not just an academic exercise; it has tremendous implications for business and society.”
Two decades and several trillion wasted dollars later, he finds that people are making the same mistakes. They claim their project is unique, so past lessons don’t apply. They underestimate complexity. Managers come out of the gate with unrealistic budgets and timelines. Testing is inadequate or skipped entirely. Vendor promises that are too good to be true are taken at face value. Newer development approaches like DevOps or AI copilots are implemented without proper training or the organizational change necessary to make the most of them.
What’s worse, the huge impacts of these missteps on end users aren’t fully accounted for.
The issue’s main article by Robert Charette is even more direct in its title: The Trillion-Dollar Cost of IT’s Willful Ignorance.
“Software is as significant as electricity. We would never put up with electricity going out every other day, but we sure as hell have no problem accepting AWS going down or telcos or banks going out.” —Robert N. Charette
The article has good information, including several examples, for anyone involved in or with a software effort.
For those considering or implementing agile or DevOps methods:
Charette notes that the same factors that cause problems with introducing any new method or platform can also derail agile and DevOps initiatives. There is a reference to a “provocative” report that claims agile projects have a failure rate up to 65%, although he rightly warns to be wary of such claims on face value. *
(the editorial and article are available without an IEEE account at: https://spectrum.ieee.org/avoidable-software-failures-cost-trillions, https://spectrum.ieee.org/it-management-software-failures; the earlier Why Software Fails article is at https://spectrum.ieee.org/why-software-fails. The Spectrum December 2025 issue also addressed medical device recalls and related software issues: (https://www.softwarecpr.com/2026/01/medical-device-software-problems-risk-patient-safety/)
We often see the same pattern of “lessons are learned but not applied” – or even lessons not learned! – in medical device software.
It’s why we use the Therac-25 example as a case study in some of our training courses. Some of the same failures – or variations on a theme – that caused the FDA to begin regulating software still occur today. A retrospective about the Therac-25 cited these factors that still occur in medical device software development and operation:
- Overconfidence in software (inappropriate use of software)
- Confusing reliability with safety
- Lack of defensive design
- Unrealistic risk assessments
- Inadequate investigation of incidents or follow-up on accident reports
- Inadequate software and system engineering practices
- Software reuse
- Safe versus “friendly” user interfaces
- User and government oversight and standards
Risk management especially rarely gets the attention required for the device risk classification. For risk management to be effective, it needs to start at the beginning of the project and continue throughout. Risk management should potentially influence architecture and design instead of maybe merely adding one or more risk controls. Risk management should certainly not be “reverse engineered” at project end to satisfy submission needs, as we have seen more consistently than would be hoped.
(The retrospective article The Therac-25: 30 Years Later is available for free at https://www.computer.org/csdl/magazine/co/2017/11/mco2017110008/13rRUxAStVR).
A relative lack of software professionals with solid medical device experience is also an issue as medical device startups and projects proliferate. Hiring skilled software practitioners from non-safety critical domains can help; however, those professionals often operate with a different and lower-level risk mindset. They need time and exposure to good medical device software practice. They may not get adequate grounding, for example, if injected into a startup needing to get to market ASAP or even a large firm with no mechanisms for building medical device expertise.
Ultimately, the answer of why software keeps failing is largely human in nature.
The lesson: don’t neglect considerations beyond technology.
SoftwareCPR can help you with software issues and risks. For 25 years, we have helped clients with medical device software development and operation, along with navigating regulations and standards in general.
We can help you with:
- Popular training courses are listed at https://www.softwarecpr.com/training/, and customized training is available.
- If you need tailored consulting assistance for your specific situation, contact us at https://www.softwarecpr.com/leave-a-message/
- Updates on regulatory, software, and other pertinent matters via our mailing list; join at https://www.softwarecpr.com/join-mailing-list/
* Interested in the merits of the 65% agile failure rate claim cited in the article? I previously did some research and can provide you with reasons why the claim is likely not accurate as stated.
