Consider this part of an early New Year’s resolution to blog more (I really am going to make a run at it in 2014). Anyway, over the holiday break I, along with many others I’m sure, was having a conversation about Healthcare.gov. I mostly mentioned all the stuff I wrote a few months ago (basically that the things that ruined the project seem to be all the regular stuff — scope creep, too many players — that ruins projects), but I also talked a bit about my disappointment with the media’s reporting of the story. Specifically, the inability to do any serious technical reporting.
The New York Times had the deepest reporting I read and that didn’t come close to actually explaining what went wrong. The story included laughable (to technologists) lines like this: “By mid-November, more than six weeks after the rollout, the MarkLogic database — essentially the website’s virtual filing cabinet and index — continued to perform below expectations, according to one person who works in the command center.” While I understand not everyone is familiar with a database, to call it a virtual filing cabinet and index only says to me that the author has absolutely no idea what a database is.
The point isn’t to pick on the Times, though. Rather it’s just to point out that as technical stories continue to pile up (NSA and Healthcare.gov were amongst the biggest media focus areas of the last three months), we’re going to have to get better at technical reporting. That I still haven’t read a decent explanation of what went wrong technically seems, to me at least, as a major disservice and a dangerous signal for society’s ability to keep up with technical change.
December 28, 2013 // This post is about: government, healthcare.gov, journalism, media, reporting
Last weekend I, like many others, read the New York Times story about the troubles with Healthcare.gov with great interest. The project was marred with things that any of us who have developed on the web have experienced working on a digital project with a launch date: Moving deadlines, late specs, different parties with different interests, and an ever-expanding scope.
The thing that was most surprising wasn’t that any of these things are at all odd, it was in fact how familiar they all sound. Take this, for instance:
Deadline after deadline was missed. The biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring, according to people familiar with the process. As late as the last week of September, officials were still changing features of the Web site, HealthCare.gov, and debating whether consumers should be required to register and create password-protected accounts before they could shop for health plans.
As I was walking down Broadway a few days later I had a conversation with another
Percolator about why it was taking so long to finish construction on the street. If you’ve spent any time in New York (or just about anywhere else) you’ve wondered how a public works project could drag on for the seemingly endless amount of time it does. But then I started to think about Healthcare.gov and how easy it is, relatively, to build digital things instead of physical things. Assuming those same issues happen on the group (scope creep, competing interest groups, etc.), for the first time I felt like I could understand what was going on. Then when you start to layer on physical accessibility laws (ramps, etc.) and the fact that you can’t launch an alpha staircase (three stairs instead of ten), it all became pretty clear.
Now this isn’t to say there’s an excuse and we shouldn’t be able to complete these projects more efficiently, but at least I could see where the time goes (and feel grateful that I a) don’t make things that involve digging up the street and b) work in a world where we don’t have to deal with the nonsense).
October 19, 2013 // This post is about: business, government, healthcare, infrastructure, internet, Obamacare
