Why healthcare.gov has so many problems

Editor’s Note: Steven Bellovin is a professor of computer science at Columbia University.

No one should be surprised by the technical problems that have plagued the new health insurance exchange website, HealthCare.gov, which allows millions of Americans to sign up and buy health coverage.

Angry, OK. Disappointed, of course. But surprised? Don’t be.

Large-scale software projects are hard. Failures or delays in schedule, budget and functionality are so common as to almost be the norm, not the exception.

Sure, the website rollout could have been handled a lot better. With all the delays and warning signs, the government could have stopped touting HealthCare.gov and teasing the public with messages such as “5 days to open enrollment. Don’t wait another minute.”

But the federal government has never had a fantastic track record in dealing with technology projects. This was not just an Obamacare problem. Most of the government has little experience in managing such a big, complex project, and management is a remarkably large part of the effort; building a system like this takes far more than just programming.

Maybe it should have hired a general contractor to supervise the 55 contractors who worked on the website. Maybe it should have looked into launching at a later date instead of October 1. But the bottom line is that technical glitches are an inescapable part of our digital life.

We see this in the private sector. When United Airlines and Continental Airlines merged, the combined reservation system didn’t work very well at first. The new Terminal 5 at Heathrow Airport outside London was saddled with software problems. Nor are tech giants immune; Windows Vista was very late because Microsoft had myriad troubles during development.

The inherent nature of software is that it demands perfection. Computers do exactly what they’re told to do. Even small errors can be disastrous. For example, one of the first American space probes to Venus was lost in part because of a single missing hyphen character in a program.

Testing is the next hurdle. Any project needs adequate time to make sure the software works properly and to find and correct any flaws. Time, however, was in short supply with the launch of the online insurance marketplace. If development took too long, there wouldn’t be enough time to test it thoroughly. That apparently was one of the problems. And even when all of the pieces are working fine, the entire system has to be tested; that can’t be done until quite late in the process.

Project management also plays a big role. It’s very hard to estimate how long a project will take. That means it’s hard to know how many programmers to devote to the task, how much it will cost and so on. Measuring progress isn’t easy, either, which means it’s hard to tell how far along you are.

The worst problem is probably that requirements change while the software is being developed. This may mean that you have to redo work you’ve already done, but the effects can be more far-reaching. It’s like building a house: If the owners suddenly decide they want a big floor-to-ceiling picture window on the second floor, it may require rerouting water pipes. That may require moving the ground-floor bathroom, which in turn could affect the kitchen layout, because the bathtub and the kitchen sink share drain pipes. Part of project management’s job is to say “no” to many change requests, but that’s not always possible.

What if more computers are added? That’s not always a solution. If the computers have to share access to resources – say, a database of people who have signed up – it gets complicated. Suppose you’ve invited many people over for dinner, more than you’ve ever hosted before. You and your spouse decide to share the preparation and cooking. Maybe you have sufficient counter space, but you still have only one sink, one stove and one oven. With two people, it might be relatively straightforward to take turns, but with three or four or more cooks, it can get crazy.

Finally, there’s the “system integration” problem of combining the different components. A system like the insurance exchanges is built in parts. Eventually, like a jigsaw puzzle, all the pieces have to be put together. Do the slots and tongues line up properly? Are the right parts of the picture on the right pieces? Did all of the contractors use the same shade of green for the grass?

There are standard approaches, standard tools and standard software for building large-scale websites. Using them correctly takes good planning and management. That was in short supply here.

The contractors building HealthCare.gov couldn’t control the budget or the timing for the regulations; those were the product of Washington politics. While there are apparent programming and design errors, it’s quite likely that most are the result of requirement changes rather than incompetence.

The overall failure appears to have been one of project management on the part of the government. In the best of all possible worlds, the site would have launched seamlessly to serve the entire nation. But software is hard. Inexperience doesn’t help. And politics just makes things messier.

The Obama administration is “excruciatingly” embarrassed and is working hard to get the glitches fixed. Let’s hope things go more smoothly the next time around.

Follow us on Twitter @CNNOpinion.

Join us on Facebook/CNNOpinion.

The opinions expressed in this commentary are solely those of Steven Bellovin.