Skip to Content

Blog

What We Aren’t Talking About With Healthcare.gov’s “Debacle”

By: Michael Diedrick on Oct 29, 2013

Tags: Security (5)

Screenshot of homepage for HealthCare.gov

To us as web developers, it’s fun when a website makes news.  More so when the President of the United States has a press conference about a bad website launch.  Even more so when a website plays a part in a great national debate.  But it’s downright fascinating to see how the website part the debate itself is just plain wrong.  The debate suggests that a website that’s slow, or doesn’t work, can prove the failure of a law.

To me, the failures of the heathcare.gov site show something else entirely. In my experience, website success is usually a question of being able to get the time, budget and buy-in to do the job correctly.  It also requires a good line of communication with the client so you can roll out what’s possible on time, change the project to fit what’s possible, and add features as they become available.  People talking about healthcare.gov seem to have this rose-colored idea of how well big websites actually work, especially when they first launch.

Let’s get up to speed.  Healthcare.gov is the federal government website run by the Centers for Medicaid and Medicare Services (CMS) to help people compare insurance plans and then get coverage though a private insurance company through a health care marketplace called an exchange.  The website is only one of 4 ways to shop for coverage (you can call, write a paper application, or work with a local community group), and it covers only the 36 states which decided not to create their own health care exchanges.  It also connects to the IRS systems to determine how much of the cost would be subsidized.

The simple fact that the heathcare.gov website didn’t launch well proves to people against the Affordable Care Act (Obamacare) that Obamacare is flawed at its very core.  Or that our federal government is incompetent. 

But come to think of it, how many big, non-internet-service websites actually work well?  Have you tried to use Sprint’s iceberg of a website?  Have you tried to use PNC Bank’s time-wasting Pinnacle website for business?  Or do anything besides buy something at America’s sleazeball registrar, Godaddy?  It seems for companies like these, sales are their first and only effort.  In addition to sales driven priorities, they realized they could replace some of their workers with technology, as humans are expensive and require paychecks.  Simply put, that’s coupon-clipping, not a technology vision.

Big internet service sites like Google, Facebook and Amazon have a great vision and work much better, and they set a standard for what good websites are and they make it look easy.  Internet service websites tend to be built with a methodology that works well on the internet: iterative often, stay in ‘beta’ for a long time, let the users help dictate the features, let form follow function, etc.  But even those aren’t impervious.  Big sites go down all the time

Because a new website is slow, has bugs, goes down a lot, or needs renovations a week after going live, well, that’s the way a lot of big websites work.  Especially for nexus websites like healthcare.gov that have to connect a variety of off-site sources to its own. 

It seems to me that the big thing we can all learn about with healthcare.gov’s crisis is about the concept of vision, and the sharing of that vision from top to bottom.

Was there vision from above?  We can assume so considering the Obama administration has proven to be very tech savvy, much like the Obama campaign before it. The top client, President Obama, certainly knows how to pick people with good vision.  And it’s something they want to go smoothly.  Even during the government shutdown, most people who worked on Obamacare weren’t furloughed at all -- they had to go in even if there wasn’t a paycheck.  So let’s assume the buyer, the Obama administration, had a strong vision.

Were the programmers given a clear line of communication to the buyers?  Who knows.  There’s a long and strange process to be a government contractor, and to comply with a myriad of US law, like HIPAA and ADA.  Word is that the contractors manage things but don’t usually get what’s actually going on.  "The firms that typically get contracts are the firms that are good at getting contracts, not typically good at executing on them," Alex Howard, a fellow at the Harvard Ash Center for Democratic Governance and Innovation, said to The Verge.  They tend to hand down decrees to the sub-contractors and there’s not a lot of chance of discussion -- they have two choices: do it or fail and get replaced.  (Same way it works with ad agencies, of which we do projects with from time to time.) 

Were there failsafes against failing?  Yeah, at least some, probably a lot more.  The front-end programmers spent a lot of time making a non-content management system site so that there was one less layer to fail.  They’re using some of the most fashionable tech out there, like Github, Jekyll and jQuery.  A development studio in DC called Development Seed created the front end, and, whether it helped or hurt in this case, they’ve been on the leading edge of tech.  (Though that didn’t stop them from making silly mistakes, like the way heathcare.gov didn’t work for people in Wyoming because they used an array for the geographic states, and included the District of Columbia as a state, but did a manual loop to 50 instead of an array count, which would have given them accurate 51.)

Is there a process and method to fix the problems?  Sounds like it.  After all news coverage, I’m sure the best and brightest are working on version 1.1 right now.  Though with some people so vested in the law’s failure, even if the website is fully fixed and ready for business there might be a small rag-tag army ready to storm the website’s server fort.

So instead of politicizing and creating hills of blame for the perceived ‘debacle,’ as it was called in the congressional hearings, let’s start talking about some of the real issues behind making technology projects successful.  Vision from above, or buy-in to vision, and a good line of communication to address project needs and changes, solid fail safes with less technology, good plans to fix problems, and of course the time and budget to do it.