One of my partners pointed this Slate article out to me about healthcare.gov. It is clear at this point that there have been a ton of embarrassing problems with the rollout of this site. I don’t want to get into the politics of health care, but I do find it interesting to look at what might be going wrong with the engineering.
The Slate article makes the point that the front end web developers (portrayed as a scrappy startup company) and the back end developers (portrayed as a shop better at getting government contracts than delivering) didn’t talk to each other and much of the problem stems from this miscommunication.
Maybe the article is completely accurate — or perhaps there’s more to the story. I’m not a JavaScript developer, but I spent a little time looking at the JavaScript for the front end of the website. There are definitely some problems.
The file eeState.js (Cardinal Peak cached copy here, original here) has this gem:
//technically we should look at the length of the stateData and not
//use 50
function getStateCodeFromState(state)
{
var stateCode ="";
for(var x=0;x<50;x++)
{
if(stateData[x].stateName===state)
{
notFound = true;
stateCode = stateData[x].stateCode;
}
}
return stateCode;
}
This is funny because the comment points out the bug, and it’s easy to fix. It’s especially funny since the array being iterated over has 51 elements — it contains the District of Columbia! My guess is that if you’re in Wyoming, you’re out of luck.
Fixing this bug would just require replacing the hard-coded 50 with this:
for(var x=0;x<stateData.length;x++)
(I would also hope that JavaScript would have some facility beyond linear search to look up elements in a collection by string, but I’m no JavaScript programmer, so who knows.)
The file eeCommon.js (Cardinal Peak cached copy here, original here) has one of my pet peeves in it:
//returns a substring of a string after an offset
//for example
// getSubstringAfterOffset("thisStringAfterOffsetIsAnotherString",
// "thisStringAfterOffsetIs")
//would return "AnotherString"
function getSubstringAfterOffset(originalString, offset)
{
var offsetLength = offset.length;
var newString = originalString.substring(offsetLength);
//TODO: add some error checking, don't have time right now
return newString;
}
Evidently the developer didn’t like the name “substring,” so they wrapped it in something called getSubstringAfterOffset(). It’s almost always bad design to create a function to do something that ends up just being a call to another single function. Just use the original function without adding another call stack and variable copy overhead! Plus, giving this someIncrediblyBaroqueFunctionName obscures the underlying simplicity — any developer looking at a “substring” function knows exactly what it does.
But I think the smoking gun here is the TODO comment. That could be at the top of every file on the entire website, as far as I can tell.
I’m not trying to mock the individual developers of this code, because there are definitely some programming skeletons in my closet, especially when I’m working under tight deadline pressure. And anyway I don’t think the fundamental problem here is “Johnny can’t code.” The whole thing reeks of a project that one, wasn’t given enough time; and two, didn’t have system-level oversight.
I reformatted the comments in the examples above so they would be legible in our blogging software. The cached versions of the JavaScript files are unaltered from Healthcare.gov on October 11.
Updated October 16 to clarify my intent was not to ridicule anyone.