Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

6 software development lessons from Healthcare.gov's failed launch

Matthew Heusser | Nov. 19, 2013
The problems that plagued the launch of Healthcare.gov in the U.S. will someday fill a book. For now, developers can apply these six lessons from Healthcare.gov's very public failure to their own software projects.

We know because at go-live the JavaScript code itself was still full of filler text that a non-decision maker typically insert onto a page or pop-up. Programmers know that something goes wrong but need to get the language approved, so they write lorem ipsum and move on. This is exactly the kind of thing that happens when people are under a deadline and can't get answers to their questions.

Mike Adams, editor of NaturalNews.com, found dozens of critical JavaScript errors by simply viewing the source and following links. Here's a small sample:

  • "TODO: add functionality to show alert text after too many tries at log in"
  • "make sure we don't try to do this before the saml has been posted if (window.registrationInitialSessionCallsComplete)"
  • "Attention: This file is generated once and can be modified by hand"
  • "Fill In this with actual content. Lorem Ipsum"
  • "TODO: maybe modify the below to use a similar method instead"

People in the organization must have known the site was not ready. Perhaps they spoke up and were overruled. We don't know.

The problem at Healthcare.gov wasn't a lack of testing. It was a lack of critical thinking. Still, the site did have a prime testing contractor. Sure, the testers didn't have months, but they did have weeks. What were they doing?

3. Testing Should Be Part of the Delivery Process
QSSI was the lead test contractor on Healthcare.gov, providing services it refers to as Independent Verification and Validation, or IV&V.

Here's what QSSI has to say about its own IV&V Process (links added):

Our IV&V services are consistent with the latest systems engineering and process improvement models, and are derived from industry standards, including the IEEE Standard 1012 -2004 Standard for Software Verification and Validation and the CMMI process maturity framework. QSSI provides an objective assessment of products and processes throughout the project life cycle in an environment free from the influence, guidance, and control of the development effort. Services include: criticality analysis, requirements analysis and tracing, software design analysis, milestone reviews and metrics, code review and analysis, document inspection [and] defect Investigation, plus training evaluation, planning, execution, reporting and witnessing.

Look at the QSSI careers site and you see a lot of focus on these standards, policies and procedures in particular, that IV&V involves tracing requirements to implementation.

That's one aspect of product risk, but it's certainly not a whole-process look. The agile manifesto changed the focus of software from "processes and tools" to "individuals and interactions" back in 2001. That same year, Joel Spolsky suggested it was possible to pass every functional test yet still have a product that isn't usable.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.