We all know by now that healthcare.gov is an utter mess. The next question: How long will it take to fix?
The New York Times this weekend had a pretty dispiriting answer:
Administration officials approached the contractors last week to see if they could perform the necessary repairs and reboot the system by Nov. 1. However, that goal struck many contractors as unrealistic, at least for major components of the system. Some specialists working on the project said the online system required such extensive repairs that it might not operate smoothly until after the Dec. 15 deadline for people to sign up for coverage starting in January, although that view is not universally shared.
That sounds bad already. But then there was this head-turner: “One specialist said that as many as five million lines of software code may need to be rewritten before the Web site runs properly.”
Five million lines of code? Well, if that seems like a lot, consider that the site as a whole apparently contains 500 million lines of code. “By comparison,” the Times notes, “a large bank’s computer system is typically about one fifth that size.”
OK, so the site is gargantuan, as measured by lines of code. These numbers are clearly meant to underscore the enormity of the task at hand in building (and fixing) a site the size of Healthcare.gov. But the software developers I’ve talked to see it a little differently. If the site really contains 500 million lines of code, they say, that’s a strong hint that the programmers involved are doing something wrong. (Microsoft’s Windows Vista operating system, by the way, contained some 50 million lines of code, and was criticized for being slow and bloated at that.) And if they’re using the number of lines of code as a metric for progress and project scope, that may be indicative of serious dysfunction in the process.
Dan Check, Slate’s vice president for technology, puts it this way: “If you contract something out and get 500 million lines of code back, there’s no way it’s going to work correctly.”
Why? Because as Jeff Atwood, co-founder of the coding question-and-answer site Stack Overflow, wrote in 2006: “Here’s the single most important decision you can make on your software project if you want it to be successful: keep it small. Small may not accomplish much, but the odds of outright failure—a disturbingly common outcome for most software projects—(are) low.”
Sure, big projects require more code than small ones. But my programmer friends tell me a number like 500 million suggests the Healthcare.gov contractors may be writing their own code in many places where they’d be better off relying on open-source external libraries. They may also be solving problems via copy-and-paste rather than more elegant programming techniques such as inheritance or polymorphism.
If true, that could be a product of incompetence, but it could also be that the contractors’ incentives are misaligned. In the 1996 PBS documentary Triumph of the Nerds, Microsoft’s Steve Ballmer explained the problem with using lines of code as a key metric for software contractors:
In IBM there’s a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand lines of code. How big a project is it? Oh, it’s sort of a 10K-LOC project. This is a 20K-LOCer. And this is 50K-LOCs. And IBM wanted to sort of make it the religion about how we got paid. … And we kept trying to convince them—hey, if we have—a developer’s got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he’s made something smaller and faster, less K-LOC. K-LOCs, K-LOCs, that’s the methodology. Ugh! Anyway, that always makes my back just crinkle up at the thought of the whole thing.
So if, as the Times piece suggests, the contractors responsible for fixing HealthCare.gov are already thinking about the task in terms of millions of lines of code, the situation may be even worse than we thought. It’s not just that the problem is large in scope—it’s that the people in charge of fixing it are going about it all wrong.
Further reading on Slate:
