2013-10-31

Co.Exist

What The Healthcare.gov Debacle Teaches Us About How To Fix Government Software

A single change--making development open source--could have saved the new site and might change the outcome of future projects.

Let's start off with the obvious: Healthcare.gov, as a web service, is a catastrophe.

Much has been written about CGI, the firm responsible for the site's backend code, and about the government's procurement process leading to CGI's selection. It is absurd that a project so vast--three years in the making with tens of millions spent already--could fail in such preventable ways.

The anger and frustration over the massive bungling of such a vital project threaten to make us lose proper perspective and learn the wrong lessons, however. So let's revisit the basics: What went wrong, how do we do better, and how do we think about government's fundamental capabilities?

Complexity breeds problems

From an end-user and technical perspective, a federal health insurance marketplace isn’t so different from a standard e-commerce website. But most of the work involved in building a site like this is not technical; it's all about client management. The project spanned numerous seemingly unrelated federal agencies, and many individual states, with a large set of specifications. These stakeholders undoubtedly provided conflicting and contradictory requirements.

Effective web startups think in terms of "agile development" and building a "minimum viable product." We experiment with bite-size pieces of a product to validate our technology and our market assumptions. If something isn't working, we make adjustments. But how can you be flexible when your final product is bound on all sides by federal law and agency regulations? What are the bite-sized pieces and optional components for an overhaul of an entire nation's health care system?

We would love to believe that a modern Silicon Valley-style tech company could have been hyper-efficient in building the equivalent of Google for health care. In today's reality, for better or worse, this is a technocratic fantasy. Outdated federal procurement practices and politicking certainly limited the set of companies considered to manage this project, but the government would still have been faced with a challenge even without these issues. The intersection of companies that produce genuinely good technology, and companies that are willing and able to navigate the built-in bureaucratic complexity of a project like this, is vanishingly small. The truth is that good software developers don't want to deal with the headaches of bureaucracy, and they have enough appealing options that they don't have to.

The complexity of this project was defined by the law itself. Perhaps one of the Republicans' most effective arguments against the bill was that it was poorly understood. A single-payer system (Medicare for all) would not only have been a simple thing to understand, it would have been an order of magnitude easier to implement. Sometimes the simplest solutions really are the best.

Open source means better software and more transparency

Even considering the inherent complexity of the project, the scope of problems with Healthcare.gov point to a staggering degree of technical incompetence and poor management. Certain aspects of the site, including the design and some of the front-end code, were completed effectively. But much of the back-end code, and the communication between the various application layers, has been fraught with bugs and scaling issues.

Perhaps most significantly, Healthcare.gov requires users to wait for the application to interact with numerous third-party legacy software systems, run by various federal and state agencies and insurance companies. This design introduces numerous points of failure and bottlenecks. Not only should these constraints have been simplified or better accommodated from the start, but a system so complex needs extensive automated and human testing. It is not clear if there were any automated tests, and we've learned that manual testing was begun a mere two weeks before the site went live (and was unsuccessful, at that).

It doesn't need to work this way. Building software is fundamentally different from building physical goods. There is no need for factories and specialized equipment. Even co-location and transportation are irrelevant. Management processes that work well for producing physical goods achieve poor results when applied to software (consider the classic “waterfall” model). Government procurement and oversight practices ought to reflect these realities.

A single change can provide the most reliable defense against repeating the current situation: All public-facing government software should be open source.

The value proposition of open source is not a hypothesis--we all use open-source software every day. The vast majority of software powering the Internet at all levels--operating systems, web servers, application frameworks and browsers--are built in full public view. Open-source code is generally at least as secure as proprietary code (and there are excellent arguments, and some academic research, showing it is more secure, though it is not a panacea). Building software in the open doesn't magically make it better, but we know that it can be done very effectively, and it provides a context of transparency and accountability. Effective, transparent, and accountable--isn't that exactly what we want from the government?

A black-box codebase allows everyone to make excuses. The administration can blame the contractor for bad technology, while the contractor can blame ever-changing guidelines. When development is done through open source, the world can see the history of what really happened. The developer community is notoriously curious and engaged. There is no chance the current implementation of Healthcare.gov could have been built out in the open without the entire country being aware of the debacle long before it went live. It is clear why the administration and private contractors would want to avoid that sort of accountability, but this is exactly the accountability that we, as citizens, ought to demand.

The future of government software

Despite the challenges, government will, and must, continue to develop software. We are used to thinking of software as a product, but government software isn't about products--it's about infrastructure.

We are still in the first few decades of the Information Age. All aspects of our society--our social interactions, commerce, wars, and even our philosophies and morality--have been fundamentally altered by how we consume and produce information. The most successful companies in the world are those that best use information to create and service markets. And in the coming decades, the most successful nations will be those that most effectively use information to service the needs of their populations.

[Image via Shutterstock]

Add New Comment

1 Comments

  • Ray Wilson

    Good points but I think if we tackled healthcare.com differently, we could have had much more success. Even with the limitations of the program.

    The hardest part of their task is verifying peoples identity. I guess it requires working with different agencies and legacy code etc. So you do that last. The easiest part would be to make a decision engine to allow for people to see their costs and choices. That doesn't require any legacy programs or working across agencies. So you do the easiest part first. Also this is what most people want in the exchange at first. Make a kick-ass tool so people can ESTIMATE how much they will get in subsidies and see their plan options. No passwords, easy access, transparency. The results clearly explain what is covered and how the doctor networks work. Oh by the way, this has been done at ehealthinsurance.com, medicoverage.com and countless other health exchanges that already existed so you could probably even skip this step and have private companies do this.

    Once you get that done you offer a greenfield application for people ready to apply. Here you don't use any legacy programs just like above and you still hold off on verification. This is hosted on separate crazy-secure servers.

    Once the applications are submitted, then you proceed with verification. You work with all the entities required. This process could take weeks but the client doesn't know this because he/she has successfully submitted the application FOR REVIEW.

    For the small subset of people who cannot verify their residence, SS # etc you deal with them then. Everyone else is greenlighted after review and starts on Jan 1.

    As far as subsidies goes. You have people estimate their 2014 MAGI and get the subsidy without verifying income. Yes, give them the subsidy based on their estimate. When they process their 2014 taxes, you make them pay additional if the got too large a subsidy.