HealthCare.gov

I’ve read extensively about HealthCare.gov, and I’ll be honest with you. I’m more than a little relieved that it has failed.

That sounds cruel, but bear with me. I’m relieved because for that project to have succeeded, given the constraints that it had, would violate almost everything I know about making software. It would be akin to saying “lets throw some bits of cloth into a dryer and see if it comes out as a sweater”.

From my perspective, as a grizzled veteran of the software world (20+ years), the list of things that were wrong with this project is staggering:

  • They didn’t have requirements until very, very late
  • they didn’t have a ‘product owner’
  • they didn’t have people with experience developing large software projects
  • they had the developers in silos
  • they didn’t have the right budget
  • they had a horrible, byzantine management structure
  • they never had a beta period
  • they had leadership that said ‘failure is not an option’. And that leadership has the power to assassinate / torture its enemies.
  • they were integrating with dozens, if not hundreds of third-party vendors

The layers of management incompetence here are incredible. No one could succeed under these constraints.

And so the project runs into problems, and what do they do? They double down on the mistakes:

  • Threats: “No one is madder than me, which means it’s going to get fixed” – Right, because scared, stressed-out programmers are the best.
  • Arbitrary Dates: “We’ll have it ready by November 30th.” – Did the developers assess the code and tell you this, or is this politically driven?
  • People: “We’ll bring in top people to fix it.” – Here’s one of the few iron laws of software: “Adding more people to a late project makes it later.”

And so what do we have? A website that has struggled with every aspect of its existence (although I admit it does look pretty). Data is lost, information is missing, errors are rampant and confusing. And everyone promising that “if we just fix this one issue, it will work.”

I am not one for swearing, but….

Bullshit.

HealthCare.gov, like every other software project in existence, is an onion with hundreds of layers. And every time you find a problem (peel off a layer), you’re going to find another layer behind it.

More specifically – when they fix a bug, it quite possibly exposes one or two or three or a dozen bugs that no-one has seen before, because the first bug was hiding them. This is another one of the iron laws of software – layers upon layers of issues that don’t reveal themselves.

You’re looking at a project that will almost certainly take many months to fix. It may take years before it is fully debugged and functional for everyone. There will be all sorts of contingencies that get put into place that will help it limp along. But it will limp for a very , very long time.

I am not saying this out of malice – this is not an ideological issue for me – this is a matter of professional pride. Software doesn’t work just because the CEO wants it to. It takes a tremendous amount of discipline and artistry and skill to make it work. And an environment that supports discipline, artistry and skill. If you don’t have that environment, you will fail.

Uncategorized

Leave a Reply

Your email address will not be published. Required fields are marked *