In previous posts about the Healthcare.gov website, I’ve been talking about how glitches are to be expected, because there’s a great deal of complexity “under the hood.” Most people never get to see what goes into a program, or even a web page. It’s not an issue of the age of the technology, it’s that it’s hard to make things appear “simple and easy.” Do it right, and everyone thinks it was easy, but to make it that way usually involves dealing with a lot of glitches. There’s often more “code” than “content” in many places.
This blog post is a good example. As you’re reading it, the site may look a little “crowded” but pretty simple, right? A title, a picture at the top, a blog roll on the right, and a “recent comments” and “recent posts” list on the left. In the middle, Norbrook spending a lot of words and lines discussing whatever topic has his attention at the moment. Not a big deal? Well, try this: Most browsers have a function called “View page source.” That displays all the lines of HTML and other coding that instructs the browser to how display the page, and what to do with various “interactive” parts, like … commenting. That will surprise you! There will be over 1100 lines of of “code,” of which this blog post will comprise… around 18 lines. Mind you, this isn’t the WordPress program, it’s just what WordPress uses to make the blog post readable on your browser.
It’s the “behind the scenes” that most people never get a chance to see. I don’t often look at source codes these days, but every now and then I get curious, and even without that, I’ve actually been a programmer, so I’m more aware of what goes into “simple.” The first programming assignment I ever had was create a replacement for a previous program, which would take the information from a standard paper form for an anti-parasitic drug test and turn it into data that could be read by an analysis program. Here’s an example I used to work with:
The form was laid out something like this:
AB12345 0320 02 01 80123 00211
010002 012011 015015 002003 008009
AB12345: The “blinded” number assigned to the drug; 0320 is the drug dose; 02 is the route of administration; 01 is the specific type of test; 80123 was the “Julian date” (the 123’rd day of 1980 in this example); 00211 was the “infection dose”; and the other numbers (5 sets of 6) were the number of adult parasites (broken into male and female) found. The entry program used to create this file had to make sure that not only was it entered correctly, it was putting everything where it was supposed to. The end result in the data file looked like this:
Just a couple of letters and a bunch of numbers, right? That’s what I saw as a line in a data file. There could be anywhere from 10 to 100 lines in a given data file. It was the “raw feed” for the analysis program.
Then the analysis program took over. It would read that line, break it up in the appropriate spots, take the “blind” drug number and send it to another database to pull back the “non-blinded” chemical ID number and its chemical name. It had to do some math to determine how effective (or not) the drug was in this particular test compared to controls, then generate a nice, easy-to-read printout of that. After that, it had to merge the individual data file into a master file.
From the user’s standpoint, this was a “simple program.” You ran it, it asked you to enter the information, checked with you to see if it was correct, and when you were finished, generated a nice, easy-to-read printout with appropriate labels and comments. Behind all that was a lot of complex work being done. The program had to determine the appropriate analysis (and comments) for each test, it had to do some fairly heavy mathematics and statistics, and it had to handle any “mistakes” without crashing.
In order to do that (as my boss at the time put it) “simple stuff” took almost 1000 lines of programming code and several months to “get it right.” Glitches, bugs, crashes? Oh yes! Something that “should work” didn’t, sometimes I got a “that’s not right” result. That’s why I ended up patching in another 250 lines of “diagnostics,” which were simply lines which made the program “stop and tell me what’s going on at this point.” Those were fairly rapidly solved, but the other problem was my boss’s predilection for asking for “simple” changes, like “do you think if this happens, it could put this comment in the printout?” Which necessitated rewrites, additional lines, and more testing. That program lasted in production for two years. Then came the “other shoe.” An archival tape was found containing all the data from a long-ago testing program, and a new set of tests were being rolled out. After a few attempts to patch the old one to handle this, it ended up being a “rewrite from scratch” project. More months of coding and testing ensued.
But here’s the thing: I knew going in what the program was supposed to do. Before I ever sat down at a terminal to type the first line of code, I had examples of the previous program’s analyses, and what was expected. The major headaches were all the “minor changes” my boss insisted on, and since sergeants aren’t allowed to scream at lieutenant colonels, I went through a lot of aspirin. It wasn’t a “develop from zero” project, and I wasn’t waiting around for (most of) “the rules. ”
That is most definitely not the case when it came to the Healthcare.gov site. While there were a number of blunders, which are being pointed out ad nauseum by various media, the thing that never gets mentioned is the role that Republican obstructionism played in this. It’s easy to think “well, they had four years” to develop this, but it wasn’t quite that simple. As I mentioned above, I knew “the rules” when I sat down to write a program. Any law, and the Affordable Care Act is no different, has to be implemented by a set of regulations. “The rules,” in other words. That impacts knowing what the program has to be written for. There were delays in the promulgation of those regulations, as well as major changes in “who is doing what.” Add in various funding issues, and you have a major headache when it comes to writing the code.
Now consider what has been happening over the past few years. The ACA was challenged in court by several Republican Attorney Generals. It took time for that to reach the Supreme Court, and much of what was supposed to be happening was in limbo until then. The Supreme Court upheld most of the law, but the “penalty” for not having an exchange or expanded Medicaid wasn’t. More regulation re-writes, and you now have a number of Republican held states deciding to not have those parts, meaning that the federal government has other things added to its plate. Continuous attempts to repeal the law in the House, along with funding cuts, a sequester, and shutdowns of the government looming. All of them due to the Republicans.
This was a “develop from zero” project. To make it even more … interesting … there was even a hard “go live” deadline built into the legislation. That would have put a lot of pressure on writing this in the first place, but thanks to the Republicans obstructionism, the delay in regulations, additional capabilities having to be added, wide variations in states’ efforts, along with funding uncertainties, turned it from a “tough job” to a “nightmare.” As I said in my first post on this, this looks like an “alpha version.” That is, the rough draft, and very likely it was. If there hadn’t been the hard deadline in place, not to mention the other political considerations, this likely wouldn’t have been seen. There still would have been glitches, bugs, problems, but not on the scale we’ve seen.
The idea behind Healthcare.gov is pretty simple. Get some information from people, give them pricing information on various plans, and let them purchase a plan that meets their needs from that. Underlying that “simple” idea, a lot of complex programming was needed to do that. It isn’t easy, and when the Republicans got involved, it got even harder.