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."