6 Software Development Lessons From Healthcare.gov's Failed Launch

The problems that plagued the launch of Healthcare.gov -- the online data hub and insurance marketplace central to healthcare reform -- 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.

By Matthew Heusser
Mon, November 18, 2013

CIO — "I spent $174 million on a website and all I got was this bad press."
— Someone, somewhere in the U.S. Department of Health and Human Services (HHS)

Well, at least someone should have said it.

Healthcare.gov is arguably the most public software failure of the decade. You may have read commentary by people who have never had to write or test code, never served on a software project, and likely don't know how to right-click and "view source" and read the HTML. That's OK; most journalists, most of the time, don't need to be very technical.

Tutorial: Healthcare.gov's Problems: What We Know So Far
More: Why is the Obamacare Website So Sick?

This article tries to go further than the typical coverage of Healthcare.gov. The amazing thing about this story isn't the failure. That was fairly obvious. No, the strange thing is the manner in which often conflicting information is coming out. Writing this piece requires some archeology: Going over facts and looking for inconsistencies to assemble the best information about what's happened and pinpoint six lessons we might learn from it.

Healthcare.gov Home Page
Healthcare.gov was a great idea. If only it worked …

1. Sprints and Iterations Do Not an 'Agile' Project Make

One of the biggest arguments about the Healthcare.gov debacle is the development method. Pundits suggest that, since war room notes use terms such as sprints and story cards, the project used an agile approach. Moreover, since it failed, agile approaches do not inherently reduce risk. Then again, CBS News claims that Healthcare.gov shrunk its schedule for testing from months to weeks, suggesting thast Healthcare.gov was never properly tested.

In agile software development, the terms "sprint" and "iteration" mean the time for a new, completed chunk of software development to be designed, coded and fully tested, end-to-end. The standard length for teams to start with iterations is two weeks; improvement beyond that generally means shortening the iteration.

How-to: 3 Ways to Be More Agile With Software Shipping Decisions
More: Can New Software Testing Frameworks Bring Us to Provably Correct Software?

Many teams use "sprint" or "iteration," only to insert waterfall concepts. Language such as "three architecture sprints, six coding sprints, two test sprints and two hardening sprints" is usually a clue that something's wrong.

But there's something else more sinister in the HealthCare.gov project.

Continue Reading

Our Commenting Policies