What Developers Can Learn from Healthcare.gov

Remember, even a failure can serve as an example of what not to do

The first highly visible component of the Affordable Health Care Act launched this week, in the form of the healthcare.gov site. Theoretically, it allows citizens, who live in any of the states that have chosen not to implement their own portal, to get quotes and sign up for coverage.

I say theoretically because I’ve been trying to get a quote out of it since it launched on Tuesday, and I’m still trying. Every time I think I’ve gotten past the last glitch, a new one shows up further down the line. While it’s easy to write it off as yet another example of how the government (under any administration) seems to be incapable of delivering large software projects, there are some specific lessons that developers can take away.

1) Load testing is your friend. If there’s a positive message that we can glean from the collapse of the portal, it is that there are a LOT of people interested in getting healthcare via the government. Unfortunately, that has led to what is effectively a DDoS attack. It has become abundantly clear that the site was never stress-tested under anything like the type of load it is encountering. The solution so far has been to put people into a queue, something that would get a site like Amazon laughed out of the marketplace. “I’m sorry, we’re a little busy right now, try shopping later?!!”

Creating realistic load testing of a site as complicated as healthcare.gov isn’t easy, but just having a thousand bots load the home page isn’t going to give you a realistic load test, especially of database transactions. You need to really bang on the core functionality of the site, and tune the heck out of it.

2) Pretty doesn’t trump functional. The site is very well designed from a graphical perspective, and is clearly using lots of Javascript and AJAX to do snazzy transitions and requests in the background. Unfortunately, it doesn’t seem to be interacting with the intermittent failures on the backend very well. If you’re going to make requests behind the scenes, you need to be very tolerant of failures. The healthcare.gov site seems to fail silently and leave a broken user experience in its wake, with no way to continue. Nothing drives a user crazy more than having to go through the same form over and over because of failures that leave them high and dry.

3) Validation logic needs to actually work. One of the more interesting early failures of the site was that the username required numbers, but the instructions made no mention of it (and neither did the failure message). It’s especially easy to get an impedance mismatch when you have both client Javascript and server code trying to do the same validations. Keeping the client code, server code, error messages and instructions in sync can be very difficult, but getting it wrong will lead to enraged users.

4) UX isn’t a luxury. User Experience is a very precise art, and when you have a site with as many moving parts and multiple paths as healthcare, making sure that the user always knows where they are, and what the next step is, is key. There have been several times during the sign-up process where I was left in a deathtrap of UI I couldn’t escape from, and it was unclear what the next step was.

The biggest takeaway though, is that the way that the federal government bids out software is fundamentally broken. There are clearly companies in the industry who understand exactly the kind of problems that healthcare.gov needed to address. Intuit’s online TurboTax is much more complicated than the sign-up process for healthcare, and it works under heavy load. Amazon and Google both handle crushing loads gracefully as well. Why can’t the government draw on this kind of expertise when designing a site as critical to the public as healthcare.gov, rather than farming it out to the lowest bidder?

Editor’s Note: If you’re interested in doing your part to improve the U.S. health care system and want to know more, get two free ebooks to spark your thinking: “Hacking Healthcare” and “Open Government.” You also may be interested in James’ follow-up piece, “You Can’t Legislate Away the Time, Money and Features Law.”

[adrotate banner=”4″]

tags: , ,