What Went Wrong with Healthcare.gov and How Can It Be Fixed? A Suggested Reading List for Managers and Developers
- Oct 31, 2013
Healthcare.gov has been plagued with issues since its launch. Although the failures of healthcare.gov have been much more visible and publicized than those of most other IT projects, the reality is that this is a typical outcome for projects of this scale. One study shows that 34 percent of projects are unqualified successes, 15 percent are complete failures which were abandoned before completion, and the remaining 51 percent, like healthcare.gov, fall somewhere in between.
Large scale software projects all tend to face the same classes of issues, so there is already a large body of research material, books, and other resources that cover the problems being faced by healthcare.gov. Let's look at some books about running a software project and recovering from failure, plus some specific guides for front-end optimization, scalability, security, testing, and refactoring to see how that advice can be applied to healthcare.gov.
Rapid Development is a brilliant guide to running a software project in the real world, where tradeoffs need to be made between defect rate, cost, and development time. There is advice on estimation, scheduling, risk management, project lifecycles, and team structure. These are topics that are common to all software projects, but which have been especially problematic for healthcare.gov.
There is an entire chapter in Rapid Development devoted to project recovery (chapter 16), which is the immediate focus of healthcare.gov.
Peopleware looks at the sociological side of software development, which it identifies as the main source of failure for IT projects. The authors' research shows that problems with communication, staffing, motivation, and other sociological factors are vastly more likely to cause a project failure than technical factors.
Healthcare.gov is a project where there are reportedly more than 50 different contractors, all working on different subsystems, with limited intercommunication between teams. There has been much blameshifting and unwillingness to claim responsibility for glitches or failures from management. With this type of toxic sociology, it is surprising that healthcare.gov works as well it does.
The Mythical Man-Month is one of the classic works on software project management. This is the book that coined Brooks's Law: adding manpower to a late project makes it later. The idea is that once the team is above a certain size, the communication overhead of adding a new person to the team will swamp any gains that person is able to make in moving the project forward.
This principle will surely come into play during the "tech surge," which is adding manpower at all levels, from developers to management.
This book is a list of best practices for optimizing the front end. Yahoo's YSlow test is a standard metric for measuring front-end performance, and High Performance Web Sites covers much of the same material along with implementation details for each tip.
Scalability Rules is a technical overview and reference on scaling web sites. Any site the size of healthcare.gov needs to address scalability issues such as caching, database optimization, horizontal scaling, and designing for fault tolerance and graceful failure, all of which are covered in this book.
In particular, healthcare.gov integrates with a large number of external legacy systems, and this appears to be the cause of much woe for the healthcare.gov team. Asynchronous communication would be a natural solution to this type of problem, and Scalability Rules has an entire chapter (chapter 11) devoted to that topic.
This is a high-level overview of the most common causes of security issues. It divides vulnerabilities, or "sins," into the broad categories of application, implementation, cryptographic, and network.
There haven't been any publicized security issues with healthcare.gov, but high-level members of management have expressed a somewhat cavalier attitude toward security. Any project that handles sensitive information, especially one of this magnitude, is bound to benefit from a careful security review. Working through the "sins" in this book and following the recommended process for code review, testing techniques, and defensive measures would be a great start.
A few of the other books in this list touch on testing, but because a lack of adequate testing was such an important issue with healthcare.gov, adding a dedicated reference to the list makes sense. Lessons Learned in Software Testing is a collection of wisdom, observations, and tips packaged into almost 300 different lessons. Topics covered include planning a testing strategy, managing the testing project, automating testing, and techniques for testing.
Refactoring describes a systematic way to take a bad design and rework it into something better. While much of this book is specific to Object-Oriented Programming, the central idea of actively working against entropy in order to improve the original design over time is a valuable one to any software project.
If the healthcare.gov codebase really does contain 500 million lines of code, as has been reported, then significant refactoring and dead code removal will need to be a fundamental part of any strategy to put the project back on the rails.
There are many more excellent books on software development that can provide insight into the healthcare.gov malfunctions. The books in this list are just a jumping off point for learning about each of the major areas where healthcare.gov has failed to meet its goals and to provide some solid ideas for moving forward.