This doesn’t help. Over on Wonk Blog, Sarah Kliff caught my attention with the headline, Uh-oh: Techies Are Finding New Problems With HealthCare.gov. But there was exactly nothing of importance in the 200 word article. And what is the big news? The team located problems further down the user experience path.
Kliff claims that “they didn’t know about” these new problems. Well, yeah. When they started on the project they didn’t know about the vast majority of problems. The hard part of fixing computer code is not the actual fixing; it is the finding. I’m sure that the people working on HealthCare.gov suspected that they would run into problems further into the process. I’m sure that when they estimated completing the fix by the end of the month they weren’t basing that on fixing just the problems they were currently working on.
What is going on is actually good news. As the developers are fixing problems with the website, they are allowing users to get further into the process. This, in turn, is allowing them to run up against problems further in. In other words: the website is becoming more usable. New problems have become apparent. Now the developers are working on these newly found problems.
This is all about framing. The Wonk Blog article could have been headlined, “Progress Made on HealthCare.gov as Developers Move to Previously Hidden Bugs.” But I guess the scare headline generates more clicks. I’ve watched as Wonk Blog has tried to burnish its nonpartisan credibility by hammering away at the healthcare website. But this one is just a cheap shot. Although new problems have been found, the developers claim that it does not change their timeline.
Sarah Kliff can “uh-oh” all she likes. But the fact is that finding bugs is what the developers are there to do. If they weren’t still finding problems it would either mean that the problems were overblown or the developers weren’t doing their jobs. And we know the problems weren’t overblown.