Obamacare Rollout: Bad Government Software

Ezra Klein, one of the biggest supporters of Obamacare the statute, has already called the launch of Obamacare a “disaster,” and it looks like things are now getting worse: as people are actually able to buy insurance, the data being passed to health insurers are riddled with errors (something Klein anticipated), in effect requiring applications to be verified over the phone. Bad software is one of my blogging sidelights, so I wanted to find out who built this particular example, and I found Farhad Manjoo’s WSJ column, which fingered CGI, a big old IT consulting firm (meaning that they do big, custom, software development projects, mainly for big companies). (See here for more on CGI.)

CGI was a distant competitor of my old company. I don’t recall facing them head-to-head in any deals (although my memory could be failing me), but they claimed to make insurance claim systems, which is the business we were in. So I don’t have an opinion on them specifically, but I do have an opinion on the general category of big IT consulting firms: they do crappy work, at least when they are building systems from scratch. (They generally do better when installing products developed by real software companies.)

The data centers of the world’s largest companies are littered with difficult-to-use, inflexible, expensive, error-riddled software. Some of it was put there by their in-house IT departments; most of it was custom jobs purchased from consulting firms. As an ordinary human being, most of it is hidden from you (except in your capacity as an employee of one of these companies), but you do get occasional glimpses: peeking at the screen of the airline ticket agent, for example. Or occasionally you’ll be on some otherwise consumer-friendly website and you’ll call up some data about your account (utility and insurance companies are likely candidates) and you’ll see your data, truncated, in all caps, poorly formatted—you’re getting a glimpse into the horror of the mainframe behind the pretty web screens.

Why is so much software so bad? There are lots of reasons. Writing good software is hard to begin with.* Big, custom projects are unique by definition, so they are sold as promises, not as finished products. Every vendor promises the same thing, so the one who promises to do it at the lowest cost often wins; when the project turns out late, bad, and over budget, too many executives have too much invested in its success to admit defeat. Consulting firms, which bill by the hour, make money by staffing projects with lots of people at relatively low cost, which is absolutely the wrong way to develop software; the productivity differentials in software are so vast that you can often get ten times as much output (of quality software) for less than twice the price, while a bad developer will do more harm than good to a project.

Sure, not every company is equally bad at either building software or buying software that works. Manjoo points the finger at one thing that is at least partly to blame: government procurement. Buying software, in the form of finished products or custom projects, is hard, and there are lots of reasons to believe the federal government is especially bad at it. The underlying problem is that government technology procurement is the province of a handful of big contractors and a handful of officials at the agencies who do the buying, and neither side has any real incentive for things to change.

As others have noted, the failure of healthcare.gov is not unique in the annals of government technology projects. But it is surprising that the Obama administration—which has tried to build a reputation for competence—did so spectacularly badly on its flagship project. Most likely, there were just not enough people in the chain of command who had enough understanding of technology to realize that things were going horribly wrong, which is a pretty clear management failure on the part of the administration.

* Although it’s not that clear that this was a particularly hard project. The thing that makes enterprise software difficult is integration to multiple back-end systems. I was surprised to learn that the integration to health insurers is done via daily files, which is just about the easiest way to do it. (Basically, healthcare.gov just has to generate one file per day, per insurer, listing all the people who bought coverage from that insurer, along with their details.) I live in Massachusetts, and judging from our exchange (thank you, Mitt Romney!) there isn’t any other integration: just some qualification logic and then the presentation of a menu of options.

This piece is cross-posted from The Baseline Scenario with permission.