Folks who hope that technology will save us from the problems we have created for ourselves (e.g. Climate Change) should take a closer look at the current Healthcare.gov website controversy. As you must know by now, the rollout of the Affordable Health Care Act (aka ObamaCare) has been rife with technical problems. Users have experienced long wait times, they are getting inaccurate information and even the insurance companies are having difficulty getting information about who has signed up as well as incorrect information. In short, people are annoyed, confused and, consequently, unhappy. Most Republicans and many Democrats are criticizing the operation of the website and the President is taking heat. However, I’m pretty sure that by the time you read this some of the technical problems will have been solved.
But how and why did this mess occur? When Google rolls out a new application, while it is not perfect, there is a general acceptance of its adequate performance and this, coupled to a trust that bugs will be identified and fixed on a timely basis causes very few ripples. Sometimes Google issues a “Beta” version that invites sophisticated users to try it out and report bugs before the actual application is released. This is a useful accepted practice in software development that will generally improve the product. So why did the US government not follow this path? Many pundits have proposed answers to this question.
Some think that anything the government attempts is doomed to be inefficient as well as costly while others quote the old saw, "To err is human; to really foul things up requires a computer." But like most complex problems there are no easy answers. Private corporations like Google have fewer accountability regulations restraining them than does the US government. When I worked for the US Navy we had a saying to the effect, “when you award the contract to the lowest bidder, what kind of results do you expect?”. While this is an overgeneralization and is unfair, it is true that choosing the lowest bidder requires less work because you will not have to justify the choice as much as you would the higher bidder. So even though the government outsources the product to a private firm to implement, not only are these restrictions passed down from the government to the subcontractor (and to sub-subcontractor etc), the communication and accountability necessarily becomes diluted and this can only cause problems. To make matters worse, the main contractor, CGI Federal has a past history of bungling at least 20 other government IT contracts: (http://www.washingtonpost.com/politics/health-care-web-sites-lead-contractor-employs-executives-from-troubled-it-company/2013/11/15/6e107e2e-487a-11e3-a196-3544a03c2351_story.html).
To make matters even worse, although CGI was awarded the contract in Dec 2011, the government did not give them the specifications for the project until this spring causing a hurry-up implementation that would almost surely be buggy. The programming process is similar to building a house for a client who keeps changing their mind about everything from how many rooms and their locations to the type of faucets in the bath. In other words, in addition to driving the contractor crazy, he will be unable to estimation the completion date because the specifications keep changing.
For an excellent graphic description of the problems encountered at HealthCare.gov, go to: http://www.washingtonpost.com/national/health-science/what-went-wrong-with-healthcaregov/2013/10/24/400e68de-3d07-11e3-b7ba-503fb5822c3e_graphic.html but be forewarned that the reference to the other main contractor, QSSI, is based in Columbia, MD, a suburb of Washington, DC and not in the country of Columbia.
In the meantime, what can be done to mitigate the debacle? Unfortunately not much unless someone slips a large patience pill into the national water supply. And we don’t have a national water supply.
A rule of thumb for software engineers is that once the code (software) reaches a certain size, it is no longer useful to make correction patches to it because they usually cause more new problems than they fix. If this is the case, it’s time to do a full rewrite and if the HealthCare.gov project has reached this tipping point, expect a loud and bumpy ride.
