Lessons from Healthcare.gov Software of the Century

The most visible software disaster I’ve ever seen is the Healthcare.gov problems that have received unprecedented media coverage and raised concerns both technical and political.

There is plenty of coverage of the saga so I won’t bother to repost or comment on all that is happening. But instead will attempt to extract some lessons that can be applied to software projects in general.

Too Many Cooks

The healthcare.gov website was built by 55 different vendors, and was overseen by the federal government itself. According to testimony to congress, there was no single vendor that was responsible for the overall delivery and quality of the application. None of the people building the various components features were accountable for overall quality.

The complexity of even simple software systems is relative not only to the number of lines of code, but also by the number of individual players involved. The lesson here is if everyone is in charge, NO ONE is in charge. 

More Read: origin overlay not working titanfall 2 

When considering outsourcing a project, make sure that you know who’s “throat you can choke” if there are delivery and risk problems, because otherwise you will be left holding the bag.

Big Bang Completion

What is referred to as “integration cost/risk” has to be paid at some point in the software project lifecycle. As you bring components together from individual developers or teams, they won’t quite fit. There will be special cases that aren’t handled properly, API calls that drifted from spec to implementation, and unexpected resource contention that will lead to performance problems.

The trick is to take that integration cost incrementally throughout the project. Ideally your teams will lock on the integration interfaces early, and then complete implementation in a continuous cycle. It’s also a great idea to prioritize a couple end-to-end scenarios and complete them first so that you can see all the pieces working together as early as possible.

If you wait until the end, you will likely spend more time correcting more code because it is built upon poor assumptions. Think of it this way: It’s cheaper to move a wall on a blue-print than once the drywall & electrical is in place.

Testing? What Testing?

It appears on this project (as in so many others) that end-to-end testing was left to the end and the results of the testing were ignored. The industry best practice (although rarely followed) is to test first. In fact, Test Driven Development says that you should define and write automated tests that express what you expect first, and then code away at the product until the tests pass. 

It’s easy to underestimate the cost (and the value!) of building a comprehensive automated test suite. Don’t make the same mistake. Think of your specification in terms of tests that pass/fail and you will be able to measure the progress and quality of your application throughout the project.

Read More: How to remove avast signature from gmail