Without commenting at all on the policy wisdom of the Affordable Care Act, it’s clear that the rollout of Healthcare.gov has been disastrous. This has been chronicled more diligently elsewhere, but can be summed up by noting that, while Healthcare.gov was plagued with bugs, crashes, and general confusion, a team of three college students replicated much of the desired functionality of the site in a few days. Of course, the alternative site, HealthSherpa, does not handle the user or data scale of healthcare.com or perform the most complex operations of applying for coverage, but the contrast between a site built for free and the ~$600+ million obligated for healthcare.gov is sobering.
We can draw a few lessons from this affair. The first is that it represents a deep structural problem of government IT projects. The process used to bid out and build healthcare.gov was not, contrary to what you might have heard, especially unique or nefarious. On the contrary, it represents the norm for large federal IT projects: mandating what should be straightforward products to be built from scratch in many ponderous phases, replete with massive sets of requirements and a commensurately high number of billable hours.
The major difference is that this time, the users are the American people. The frustration of grappling with subpar technology is the same experienced daily by some of the most vital people in our public service ranks. Soldiers, intelligence analysts, law enforcement officers, and veterans care workers, to name just a few, are routinely forced to implement tools that are barely functional, told to simply “make it work”. This is by no means meant to minimize the headaches associated with healthcare.gov – on the contrary, it points to the need for real, systemic change.
There are two fundamental flaws at work in the legacy government IT acquisitions model. The first is that the same procedures used to acquire tanks and aircraft carriers are used to build software. Yet software development is by nature a creative, generative, iterative process, not a static set of requirements that won’t change significantly over the lifecycle of the product. And while good software is never truly finished, the essential building blocks can often be delivered right away - the key is that you’re creating a basis for iteration and creative enhancement, not obediently following the same blueprint for years at a time.
The second, and subtler, flaw is the failure to recognize that America in general, and Silicon Valley in particular, are unique in the ability to build software. Many remarkable advantages of American life have contributed, in turn, to our dominance in software development. Pondering an increasingly data-driven future, our abundance of software talent has to be considered one of America’s most strategic resources, and leveraged and fortified accordingly. Sadly, in the current IT acquisition landscape, armies of contactors are paid by the hour to produce a crude facsimile of what our best software artists could create for a tiny fraction of the cost - but ignoring such a precious asset would be a mistake at any price.
One great irony of the healthcare.gov fiasco is that a major rationale for the Affordable Care Act was the idea that Americans can do better than the legacy healthcare system – only to see what should have been a slam-dunk website rollout crippled from the beginning by the IT acquisitions machine, another legacy system. Regardless of one’s views about the law itself, though, one saving grace is made clear: if we want to do better, doing what we’re already the very best at seems like a good place to start.