Why HealthCare.gov is still a mess

Case study of a rush job

No question about it: HealthCare.gov is a wreck.

What's tougher to pin down, at least from the outside, is what's broken, how it broke, and what's the best way to go about fixing it.

Early reports about the HealthCare.gov being unresponsive and flaky came flooding in within the first few hours of the site going live. The most crucial part of the site, the sign-up system for the FHIM (Federal Health Insurance Marketplace), turned out to be the most problematic.

What HealthCare.gov got savaged most for, though, was being just plain hard to use. The Washington Post's Wonkblog attacked the site on multiple fronts for its bad design aesthetics. Prompts were confusing or contradictory, the sitemap was a torrent of hard-to-appreciate information, and forms returned uninformative errors. The FMS Software Development Team Blog was equally critical. A form could take as much as half an hour to submit and might not return anything but an error.

A week has gone by since Healthcare.gov site went live, and it's still plagued with problems.

What went wrong?

An initial round of criticism focused on how many files the browser was being forced to download just to access the site, per an article at Reuters. A thread at Reddit appeared and was filled with analyses of the code. But closer looks by others have teased out deeper, more systematic issues.

The architecture for the site -- one live server, one backup -- was touted as being lean and ready to scale via a CDN. In fact, a CDN was used: The site's static files are served through Akamai. But it clearly isn't the static front end that has been the issue.

Slate pointed out that one of the errors returned from the site hinted at an Oracle database problem, apparently because "the front-end static website and the back-end servers (and possibly some dynamic components of the Web pages) were developed by two different contractors," Development Seed (front end) and CGI Federal (back end).

Another analysis by AppDynamics founder Jyoti Bansal, as seen in the Washington Post, came to a similar conclusion: The back end was the bigger culprit. He noted that adding server capacity probably wouldn't change anything. "It’s like you have four lanes in the highway converging into three lanes of a bottleneck," Jyoti said, "If your software isn't designed to reach all the lanes, that will happen."

Source code for the site has since been published on GitHub -- it's built with Ruby and Jekyll -- but that repository does not include any of the actual data for the FHIM. As the Huffington Post pointed out, there's no development history for the code -- it's all been checked in as a single commit.

What's most embarrassing is how back in June, the Department of Health and Human Services -- and Development Seed, to boot -- stepped up to crow in the pages of The Atlantic about how great the site was going to be. Designer Ed Mullen put it this way: "We're comparing ourselves to Rdio and similar services. We want to be aligned with the current thinking of the Web."

John Pavley at the Huffington Post felt that on looking at the code, the core of the problem was clear: The site was a rush job. "[T]hey started out in good shape but tried to do too much, too soon. There are many unoptimized files left on the site, which they seem to have rushed out the door.... If they want to live up to their initial promise and completely open source the code on GitHub.com, I'd bet thousands of developers would volunteer to fix all of their bugs for them."

The problem might also have stemmed from the budget alloted to the whole project. Back in April, the Washington Post noted how building the health care exchange was estimated to cost at least $5 billion to implement. Congress alloted only $1 billion, so Health and Human Services patched together the needed budget from a number of other, different federal allowances. It's not hard to see how one of the victims of such a lean budget was a proper test framework for the needed infrastructure.

Developers are already gleaning lessons aplenty from the early failure of HealthCare.gov. James Turner at programming.oreilly.com cited four major takeaways: do load testing; "pretty doesn't trump functional"; validation logic has to be, well, valid; and user experience is "a very precise art."

"There have been several times during the sign-up process where I was left in a deathtrap of UI I couldn't escape from," Turner complained, "and it was unclear what the next step was."

How bad is it when even the IT experts themselves can't navigate your product? Real bad.

Turner went on to point out, as many others have, that this sort of behavior would be unacceptable from any commercial entity. "The way that the federal government bids out software is fundamentally broken.... Why can't the government draw on [the expertise of Amazon and Google] when designing a site as critical to the public as healthcare.gov, rather than farming it out to the lowest bidder?"

At least the government is admitting it has a problem, but it had better hurry if they want things to be working by the time the Dec. 15, 2013 enrollment deadline looms.

This story, "IT experts: HealthCare.gov is still a mess," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.

This story, "Why HealthCare.gov is still a mess" was originally published by InfoWorld.