Healthcare.gov’s buggy launch contains lessons for developers

Healthcare.gov’s buggy launch contains lessons for developers

on Oct 11, 13 • by Chris Bubinas • with No Comments

The long-awaited October 1 rollout of the federal government's online health insurance marketplace HealthCare.gov, a critical piece of the Affordable Care Act, was marked by slow performance and trouble for users looking to sign up for new insurance services...

Home » Code Refactoring, Static Analysis » Healthcare.gov’s buggy launch contains lessons for developers

The long-awaited October 1 rollout of the federal government’s online health insurance marketplace HealthCare.gov, a critical piece of the Affordable Care Act, was marked by slow performance and trouble for users looking to sign up for new insurance services. Many users reported being unable to log into the website, and, while the Obama administration reported more than 8 million unique visitors in the exchange’s first week, the total number of people enrolled during that period was likely in the low thousands, several sources familiar with the technology told The Wall Street Journal.

What caused the problems?
While the initial problems were credited to unexpected volumes of Web traffic placing strain on servers, later reports from both federal officials and experts in the software industry have suggested that the performance issues had to do more with myriad flaws in the site’s software rather than underlying hardware shortfalls. An analysis commissioned by The Wall Street Journal suggested that the site was built on a poor foundation, that it contained large amounts of extraneous code and that it did not capitalize upon basic Web efficiency techniques.

Experts told Reuters that the site contained a number of particularly resource-intensive features. For instance, pressing the site’s “apply” button prompts the site to handle an unusually large amount of data, mostly in the form of JavaScript files and plug-ins. In effect, each visit to the site was performing a miniature DDoS attack, web design expert Matthew Hancock told the publication. Additionally, one of the main problems appeared to be in the identity-checking and security functions, which seemed to rely on a poorly architected system that made a large number of calls to a separate server.

In addition to these design and scalability problems, there were a number of issues that simply amounted to buggy code, according to AppDynamics founder Jyoti Bansal. Speaking with The Washington Post, he explained that the number of error messages on the site suggested that the code had not been fully tested.

“Most of the problems like these are in the software,” Bansal told the news outlet. “Hardware is the easy part. You can add more hardware and do it easily. Software takes more time. In the rush of getting this out, it seems like testing wasn’t done completely. My expectations from this is that these problems should go away in the next few weeks.”

What can developers learn?
As the site continues to weather critiques and undergoes a redesign, developers can draw on the events of the unwieldy launch for lessons with their own products. Two points worth taking away include:

1. Function and design are equally important: Several onlookers have noted that the site looks beautiful despite its errors, suggesting a disconnect between the front-end development and the back-end. This disjointedness is likely due to the fact that there were, in fact, two separate vendors contracted to build the site, Slate noted. Many of the errors can be attributed to poor communication, as well as isolated testing processes that examined individual components rather than end-to-end processes. One of the most visible early problems was that usernames required numbers (a back-end decision), but the instructions didn’t mention this rule (a front-end decision), setting up an incredibly simple error that was almost impossible for users to navigate around. Using tools like code review software to coordinate oversight of the full site’s architecture could have helped unify front-end and back-end design.

2. Testing is essential: Given the scalability issues with HealthCare.gov, there appeared to be a shortfall in load testing, according to several experts. While the amount of traffic the site experienced appeared to have been well beyond projections, load tests should be run with twice the anticipated peak load to catch potential glitches, Bansal told The Washington Post. On the other hand, anticipating the load can be tricky. U.S. Chief Technology Officer Todd Park told USA Today that the site was drawing around five times the anticipated number of simultaneous users. Planning for that kind of demand requires thorough load testing.

But there’s more testing to be done before a launch than simply determining whether an application will be able to handle large amounts of traffic. It’s also important to locate faulty code – or unused and redundant code, as in the case of HealthCare.gov – through the use of tools like static analysis software.

“Ninety percent of the effort is really finding what to fix,” Bansal explained. “Making the coding changes is only about 10 percent.”

With static analysis and code refactoring, it’s possible to validate the code, catch logical errors and eliminate unnecessary components. While HealthCare.gov’s overhaul will inevitably bring functionality to its users, the development lessons its initial hiccups contain are essential for any ambitious application launch.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top