After two months of intense controversy, criticism and debate, the Obama administration recently announced that the troubled Healthcare.gov website had reached an acceptable level of functionality in time for its Nov. 30 overhaul deadline. While acknowledging that further repairs would be needed, officials explained that that they had met their target for making the site usable for the “vast majority of users” by the end of the month.
Web page loading times now are less than one second, as opposed to eight seconds in late October, the Los Angeles Times reported. Additionally, the rate of timeouts and other Web page failures has dropped from 6 percent in October to less than 1 percent, and the system has gone from around 40 percent uptime to more than 90 percent uptime. The site, launched Oct. 1 as part of the Affordable Care Act, had been prone to a large number of errors and failures, and it suffered from a bloated code base, tangled development methodologies and apparently inadequate testing.
In the wake of the launch, a large number of lessons for developers have been brought to light. While many more are likely to become clear, some of the key considerations that development teams should take away, according to consultant and CIO contributor Matthew Heusser, include:
1. Plan for the real challenge of building a 100 percent perfect system: By law, Healthcare.gov was required to do a large number of things – verify enrollee data from multiple government systems, have transactions automatically go through to insurers, etc. – and it was required to deliver all of these functions perfectly. A lightweight alternative called Opscost that emerged in the ensuing weeks let users access a key function – getting rate quotes – without the same backend heavy lifting.
While the demands of the two applications were clearly different, there’s a lesson from Opscost: Building a simpler version of software that delivers key features first is one of the best ways to ensure functionality out of the gate. If the system has to be 100 percent perfect on launch, companies can still benefit from an iterative, agile approach that builds the application in smaller, functional chunks and tests each for errors using source code analysis tools as they are delivered.
2. Ensure testing serves a purpose: All the code review practices, static analysis testing and quality assurance teams in the world aren’t going to have much effect on the software if testing is treated simply as an item on a checklist, Heusser wrote. QSSI, the contractor put in charge of testing for Healthcare.gov, has a lengthy set of frameworks, standards and policies it claims to use when testing programs, but the evidence of pre-release testing appears almost nonexistent.
“The entire process is firefighting,” Heusser wrote, explaining that the only issues reported were trouble tickets in the field. Additionally, there appears to be no record of people pointing out known issues that might result in a no-go. Without pre-emptive testing – and the ability for the people running tests to halt the release until bugs are addressed – an application is in trouble.
3. Make sure problems are identified and addressed early on: Whether it means building and testing in smaller, functional chunks or ensuring source code analysis is applied and paid attention to on a regular basis, development teams have a responsibility to be considering code quality and security long before they put together a finished product and go back to test it.
“Use incremental approaches such as betas, early testing and regular delivery of a completely tested system, in tandem with flexible scope to find risk before it finds you,” Heusser wrote.
Whether developers are undertaking an ambitious government project or a simple mobile app, these principles are essential for ensuring quality is a concern at all stages of development.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.