Sunday, October 20, 2013

HealthCare.gov: Boat of Gloat v.5a

I found this article, Bad Government Software, at baselinescenario.com from James Kwak:
Ezra Klein, one of the biggest supporters of Obamacare the statute, has already called the launch of Obamacare a disaster, and it looks like things are now getting worse: as people are actually able to buy insurance, the data being passed to health insurers are riddled with errors (something Klein anticipated), in effect requiring applications to be verified over the phone.
Oh, my. I hope the insurance comapanies staffed up to verify millions of applications by phone.
I wanted to find out who built this particular example, and I found Farhad Manjoo’s WSJ column, which fingered CGI, a big old IT consulting firm (meaning that they do big, custom, software development projects, mainly for big companies).

Why is so much software so bad? There are lots of reasons. Writing good software is hard to begin with.* Big, custom projects are unique by definition, so they are sold as promises, not as finished products. Every vendor promises the same thing, so the one who promises to do it at the lowest cost often wins; when the project turns out late, bad, and over budget, too many executives have too much invested in its success to admit defeat. Consulting firms, which bill by the hour, make money by staffing projects with lots of people at relatively low cost, which is absolutely the wrong way to develop software; the productivity differentials in software are so vast that you can often get ten times as much output (of quality software) for less than twice the price, while a bad developer will do more harm than good to a project.
All completely accurate, echoing many of my observations and repeated real life experience. What happens to the most awful big systems? The best outcome is it gets shut down and abandoned with lessons learned and a few careers ended. That is possible with in-house systems because the rest of the world doesn't have to know. With a system that has been unleashed on the unsuspecting public, it can't just be abandoned. It has to be fixed or replaced while running, neither of which is ideal or easy, Both are expensive. CGI, and each vendor involved will probably rake in mad stacks trying to fix the bugs, depending on how their contracts werw structured.
As others have noted, the failure of healthcare.gov is not unique in the annals of government technology projects. But it is surprising that the Obama administration—which has tried to build a reputation for competence—did so spectacularly badly on its flagship project. Most likely, there were just not enough people in the chain of command who had enough understanding of technology to realize that things were going horribly wrong, which is a pretty clear management failure on the part of the administration.
Bazinga!

To make matters so much worse, the President still doesn't understand the scope of the software disaster. He thinks the vendors hired by HHS to create this frankenstein can slip in a couple of patches, like an Apple IOS update, and everything will start working. That analogy shines a spotlight on his lack of understanding of software development. A better analogy would be Duke Nukem Forever.

2 comments:

  1. I hope the insurance comapanies staffed up to verify millions of applications by phone.

    No hiring needed. The technology is already in place.

    What Is a Phone Queue System?

    Agents fielding calls receive them one at a time. They may also be able to see how many calls are waiting and for how long.

    Sarcasm begets sarcasm! ;)

    ReplyDelete
  2. Stagflationary Mark,

    Haha! They could have skipped the whole web system and just set up a phone bank with a thousand operators (working 29.5 hours per week so as not to quality for health coverage).

    ReplyDelete