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.

"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.

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.

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.

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.

2. The System Produced the Outcome, Not the Lack of Testing
If you've worked on a waterfall project with a defined test phase, you know it's not really a "test" phase at all. Once the first show-stopper bug is found, it's actually a fixing phase.

To state that Healthcare.gov wasn't fully tested implies that the test group either never found any show-stopper bugs or didn't have the ability to halt the project. Given the legally required go-live mandate, the second option seems realistic.

One thing we do know for sure: The organization rushed ahead with coding before it knew answers to questions. That's no recipe for success.

 

1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.