I’ve resisted commenting on the healthcare.gov situation for a few reasons
- I don’t want to get dragged into partisanship.
- I don’t have any specific knowledge or involvement in the project beyond what I’ve read in the papers.
That said, I think that the healthcare.gov situation is a teachable moment that could potentially be used to begin a larger discussion of the state of the practice of software engineering.
For starters, here’s a link to an NPR story about the project:
The slide shows a lot of problems
- First, a waterfall approach was used. Instead of setting up a series of small releases, each of which implements a specific function, the plan was to deliver the whole system in one iteration. This approach appeals to managers because the project plan is simple to understand, has definite milestones, has a fixed duration, and so forth. But as we’ve seen in this project, these presumed “advantages” can turn out to be illusory.
- Second, requirements continued to change throughout the life of the project. This is a common occurrence, but it can easily derail a “waterfall” project. Late changes to requirements mean that the design must change, and the implementation must change as well. So instead of doing an implementation once, you end up reimplementing the same functionality over and over as requirements change. So you end up with a de facto iterative approach, except that instead of implementing a new function with each iteration, you end up reworking the same function over and over. In this situation, it’s possible to keep churning indefinitely and still never end up with a completed project.
- They stuck to their end date, even though the requirements changes had continued past the original period when development was planned to be complete. This is another recurring problem in the industry. I’ll bet that there were many, many meetings where the phrase “Failure is not an option” was said. Well, failure is always an option. You recognize that it could happen, you look for things that cause it, and you mitigate those causes. If you don’t do these things, you’re inviting failure. If a project is well behind schedule and the delivery date is looming, the only workable answer is to do triage. Figure out what you’ve got working, realistically figure out what you can get built by the date in question, and defer the rest to another release. The more common approach is to double down — say that all features will be delivered on the original date, and “just work harder.”
- They did little testing. This is another classic blunder with waterfall projects that slip their schedule. If your plan is to complete the development process before you start testing, and your schedule slips, your window for testing gets smaller and smaller, and may even vanish completely. You’re already doing “just work harder.” You’re putting in 14 hour days. Everyone is in a state of barely-suppressed panic. The due date is rapidly approaching, and you still haven’t implemented all the requirements changes. So what happens to testing? More often than not, you just hope for the best and release what you’ve got on the due date.
If you work in this industry, you’ve seen these things happen over and over again. More often than not, they lead to a bad end. So why do we still keep doing these things?