Why The Experts Are Probably Wrong About The Healthcare.gov Crack-Up

Many technology experts are blaming the software behind Healthcare.gov for all the problems Americans have encountered while trying to sign up for health insurance in accordance with the Affordable Care Act.

That's not how I see it.

A look at Healthcare.gov's source code, on its own and through a couple of Google's performance-analysis tools, tells the story of a rush job, a website that seemed to start with the best of technical intentions but was opened to the public before it was ready.

You can supposedly find the software that powers Healthcare.gov on a publicly available GitHub.com repository. But it's a sanitized repository: All of the development history is missing. There is just one massive check-in of the code, called an "initial commit," which was uploaded three months ago. This indicates that, despite all the hoopla and

The initial software architecture and tech stack designed for Healthcare.gov is modern and rational. When you design a website for millions of people to access every day, you want as few moving parts as possible. Healthcare.gov is based on Jekyll, a very innovative approach to scaling a website to accommodate thousands of requests per second by transferring most of work from the server to the user's browser. Theoretically, Jekyll harnesses the power of the user's computer and takes the load off the government servers. The other technical components of Healthcare.gov are just as innovative: Bootstrap, jQuery, Backbone.js, Underscore and JSON. These are not the old-fashioned horseless carriages of the Internet, they are the technological equivalent of the Tesla Model S and the Toyota Prius.

If the developers behind Healthcare.gov had stuck to the plan, they could have had a super-scalable website available to the American people to run at a relatively low cost.

Clearly that's not what we have. We have a slow, buggy and frequently unavailable website that's attracting criticism from every corner of the Internet, including a Reddit conversation on "How not to optimize a website."

The more I look at the code and the more I read about Healthcare.gov, the more I'm convinced it's not the architecture or tech stack, it's the scope of the requirements. Which is to say, they 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.

As it is, Healthcare.gov has too many client-side features, all of which have to request files and resources from the government's servers in real time to respond to user requests. That means many more roundtrips between the browser client and the backend servers, which defeats the whole purpose of Jekyll and all those other shiny new technologies.

When you have to meet a deadline in front of millions of people, you have to limit your scope, you have to keep the design simple, you have to build an MVP (minimum viable product) and then add features to support real-world traffic over time. All of today's most popular websites, handling millions of users, such as Google, Facebook and The Huffington Post, were originally built with a tiny feature set that has expanded gradually over time.

I can't get very deep into Healthcare.gov to do a more complete analysis because it keeps booting me out. So the developers behind Healthcare.gov are on their own. 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.

That's the power of open source and open government: Other people are invested in fixing your problems for you!