Yesterday morning, Erza Klein published that caused a bit of a kerfluffle. It was very blunt, calling the rollout a "failure" and a "disaster". And it caused quite a few left-leaning websites some uncomfortableness, since these criticisms are, unfortunately, very accurate. Put simply, the website is a mess. But, this isn't quite the catastrophe some (especially those on the Right) are making it out to be.
First, a little background about me: I've been working in IT since 1995, and I have worked on multiple web-site launches for both the federal and state governments. I spent 8 years working for a contractor in Arlington, VA, helping to design and launch websites for the Pension Benefit Guarantee Corporation (PBGC), ENERGY STAR, and the USDA. I spent 3 years working for a contractor in Tysons Corner, VA that worked with the Navy Personnel Research and Development Center (NPRDC) in San Diego. I spent a year working for the state of Delaware, helping them launch a new website that allowed companies to incorporate in the state. And, just to balance that experience, I also spent two years working for a dot-com in Rockville, MD back in 1999/2000, coming in with them months before their site launched.
I do not have any direct "insider information" about healthcare.gov or any of the state exchanges. I have not worked for the Department of Health and Human Services, which oversees the Obamacare website. But, the combination of the experience I outlined above, along with extensive reading and research I've done over the past two years about this issue does provide me with a bit of insight on what's going on right now.
For many people, the rollout of the healthcare.gov website was yet another example of "the government can't do anything right" - confirmation bias of something they already believed. However, the federal government itself did not create the website. They hired a contractor, CGI Federal, to create the site, perform testing, and launch it. (In a really disturbing bit of news, according to the very Right-leaning Washington Examiner, CGI Federal was . I cannot confirm if this is true, but it would explain a lot.)
Now, this is not to say that the Obama Administration and/or HHS had nothing whatsoever to do with the development of the site. There are many people inside of HHS that know a great deal of information about the PPACA, the exchanges, the difference between gold and silver plans, how the subsidies work, etc. They are the subject experts in the program itself. But, by and large, the federal government has no idea how to design, create, Q/A, or publish a web site. They don't employ programmers: they hire contractors who employ programmers, and those contractors collect information from the government agency (in this case, HHS), write proposals which are then approved by that government agency, and then create a development and/or test version of the website on their own systems. Certain employees at HHS would be updated regularly on the status of development, and would be shown regular demonstrations of what the site currently looks like.
However, there are a few issues with this process that make it very difficult for the government agency to be able to accurately assess the progress as the development is happening.
1. As I said above, the agency does not know how to build or launch a website. The biggest problem with this fact, is that it means they do not know how to properly test it: oftentimes, they have no idea what the term "load testing" means. This was an obvious problem with healthcare.gov, and I've seen it on multiple sites before. Basically, it means that if you are demonstrating the website to your client, everything looks great - because you are the only person on the site at the time, and it has no trouble whatsoever handling one request at a time. However, if you have 100 people on at a time? 5,000 people? A million people? Well, then you get what we saw on October 1:
There are programming tools and software packages out there that are specifically designed to simulate this kind of testing, and can measure the system performance as more and more users are added - this is called "scalability". But, if the contractor for some reasons decides not to do any load testing (or runs out of time before the launch date to do it properly), then they don't do much good.
The good news about scalability problems is that they can often be solved in the easiest way possible: "Throw money at the problem". Buy new servers, faster servers, more memory, increase your bandwith, or anything else that can be solved by the purchase of materials. The bad news is that sometimes the problems are caused by the website code itself, and this is infinitely more difficult to fix, since it is usually caused by a design decision that was made months or years ago, and is now part of the system architecture itself. Once again, this is fixable, but 1) it can't be done with money, or simply adding more programmers (there is actually a concept in software development called , which states "adding manpower to a late software project makes it later"), and 2) it requires competency on the part of the programmers that you do currently have: to recognize the problems, fix them quickly, and (most importantly) DON'T ADD NEW ISSUES TO THE SYSTEM.
2. Hiding system design problems is pathetically easy. Usually, the client counts on the contractor to supply them with the various "Use Cases" - examples of a typical user experience that would/should reflect what a "real" user will go through when trying to use the site after it launches. However, if there's a known bug with some specific piece of information - such as, say, signing up for health insurance in Maryland is a nightmare - then you simply don't include signing up in Maryland as one of the use cases. And then, you pray you can fix the problem before anyone stumbles on it on their own.
3. Like any working relationship, one side or the other can be either incompetent or just very unpleasant people. You can read about my experience with the latter situation .
In the interest of fairness, there was that proposes the theory that the Obamacare site is trying to "hide" the true costs of coverage from the public by collecting a fair amount of personal data and connecting with multiple other systems before displaying any possible choices.
Unfortunately, Avik Roy is . This article is no exception: it's basic point is that the personal information is needed in order to determine any possible subsidies the web site user might qualify for. Calculating these subsidies is not simple: the healthcare.gov site has to interact with an identity verification system from Oracle, two sets of software created by contractors, and the credit-checking site Experian PLC. Obviously, the more outside systems you introduce, the higher potential you have for an information "traffic jam", which can slow down or crash the entire site. However, that's not Mr. Roy's issue with the web site.
His issue is: "by analyzing your income first, if you qualify for heavy subsidies, the website can advertise those subsidies to you instead of just hitting you with Obamacare's steep premiums. For example, the site could advertise plans that "$0? or "$30? instead of explaining that the plan really costs $200, and you're getting a subsidy of $200 or $170."
Think about this for a moment. What kind of business would even consider advertising only the highest possible price for their product to potential shoppers? (If you answered "One that wants to go out of business fairly quickly," congrats - you nailed it.) If you were shopping for a car that cost around $20K, and the car manufacturer's website told you on their first web page "This car costs $40K. Are you interested?", under what circumstances would you say "Yes"? Why would the manufacturer make you click on multiple pages before informing you that through a combination of sale offers, discounts, rebates, and tax breaks, the car is actually only going to cost you $20K? Why would any potential shopper be more concerned about the highest possible price, rather than the price they themselves are going to pay?
The problems with the website and its launch are large and varied, but by no means insurmountable. And, as Ezra Klein pointed out at the beginning of his article: "The hard question is whether the launch will still be floundering on day 30, and on day 45." Whether or not that happens is at this point dependant upon an intangible, unknowable factor: the competency of the people who will be assigned to fix it. I've been there before, and I have faith - but I do wish them luck.
Full Post
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment