A Diagnosis of HealthCare.gov's Difficulties & The Reasons for Them

Ugo O.Gagliardi

  1. Introduction

    I used to decry, during my Harvard seminars on software engineering, the scandalous lack of standards for our profession. I used to make two points, viz:

    The development of HealthCare.gov may very well be such a catastrophe. In this note I will opine on what is happening and why. While separation from the official records and advanced age may be an obstacle, my experience in reviewing many many large scale software development projects (over 30 years) may give me some small critical advantage.

  2. Sources of Complexity

    It is my belief that the major sources of complexity for HealthCare.gov are:

  3. Management & Procurement Structure Flaws

    The Federal Government procures large scale administrative systems using a very poor strategy which can be summed up as a "minimum bid strategy" (MBS). While MBS makes sense, from a political point of view, since it seems not to squander tax payer moneys, it actually makes no sense whatever from a software engineering (SE) point of view. In fact, SE, especially of complex systems, is much more of an art than either science or engineering. Just as you cannot save money by hiring a thousand 4th rate tenors instead of a Pavarotti, you cannot save money by hiring a lot of warm bodies who can write bad to mediocre code.

    Studies done in the early 60's showed that programmers' productivity ran over a huge range with genius programmers producing as much as 25 times the code produced by mediocrities.The geniuses' code was, in general, much better by having far fewer bugs and running faster! In this kind of art going for cost of man hours is as foolish as asking Hollywood, or Broadway to select artists on the basis of man hour costs.

    HealthCare.gov is not uniquely bad from this point of view, I have seen many systems in such straits. Some were never successfully completed.

    Besides these serious problems with the procurement of Fed's admin software development, this project is affected by serious management structure problems. The project, allegedly, involves 55 contractors, with no general contractor apparently in charge. In fact, a senior official of the lead contractor testified to a House Committee that the government (CMS department of HHS) was responsible for the testing of the system. I can categorically state that this is a totally unacceptable position to take on either professional or business basis

  4. Major Architectural Flaws

    HealthCare.gov has two major [system] architecture flaws. The first has been widely reported in the press with clear characterizations. Namely, that the browsing function requires that new users complete the full registration before they are allowed to browse. Apparently the system originally allowed an "anonymous" mode in which users could browse without registering. Reportedly this mode was eliminated by a request made by either the CMS (Center for Medicare & Medicaid Services), or its higher echelon HHS, or possibly even by the White House itself. This decision is a disaster from a technical/engineering point of view.

    In fact, it forces all the browsing traffic to go all the way to the data hub & back. This greatly increases the congestion of the data hub servers and the central portion of the network. At the same time, it dramatically slows the system's response to browsers.

    If HealthCare.gov had been designed, as virtually all commercial websites are, to allow browsing before registering, the system could simply download some relatively small files into the users' device memory and keep virtually all the browsing traffic at the users' computer.

    The rationale, for this deeply flawed decision, must be that somebody believed it fosters a tighter populace control and intelligence by HHS or higher level.

    The publicly stated rationale, namely, the need for accurate information on rates and subsidies, does not stand up to close inspection.

    The second major architecture flaw is the deep automation of the back room operations.In fact, HealthCare.gov is based on a data hub which serves the requests from the web site users'. The data hub has the tough job of accessing the internal data base of several Federal agencies (IRS, SSA, CMS/HHS, VHA) while, at the same time, allowing fast and coordinated access by hundreds of thousands, if not millions, of simultaneous users.

    As learned in the last two decades, this is a very difficult and tricky data base design job. I predict that the problems we have seen so far are just the trivial ones. The data hub will have huge performance, data coherency (accuracy) and security problems which will not be solved by the currently targeted date of Nov. 30, 2013.

  5. Has Modern "In The Cloud" Technology Been Used?

    An even more important technical issue is what is the foundation of the data hub?. At this time I have no knowledge of what foundation is being used for HealthCare.gov. If the wrong foundation is being used then this system will never achieve the throughput or performance necessary to handle hundreds of thousands or even millions of simultaneous users. From what I have seen in the media it is unlikely that the system is using the right foundation. If this is the case the system will not operate in an acceptable fashion by the advertised date of Nov. 30, 2013.

    Fixing the significant design problems for the data hub and its resource management foundation will require involving a completely different class of contractors. It also will require one to two years.