Last week I had to chuckle when Mr. Zients announced that "by the end of November, HealthCare.gov will work smoothly for the vast majority of users." I am one of the few long time www.healthcare.gov visitors and have been anxiously looking forward to improvements since 2010 when I first complained the insurance finder was useless. Although I admire his chutzpah the two things I can say for sure is that there will be a touchdown dance on November 30th and there will still be a lot of serious problems to fix. The touchdown dance is the easy part of his task. Unfortunately the American people are married to this software. Like a bad Las Vegas wedding in which we hate to admit our mistake, we will trudge onward for the sake of the children.
The first problem facing Mr. Zients is that he is up against the software engineering and project expertise of Fred Brooks, whose central theme in his book, “Mythical Man Monthâ€, is that "adding manpower to a late software project makes it later" has been ignored by the administration. They have already announced their plan to hire QSSI to come in and fix the problems with the web site in 30 days. Adding more people and thinking this will fix the problem is a big problem. Saying that it has to be done in 30 days has me in alternating fits of laughing and crying. As a person who has made his living fixing “other people’s code†for thirty years, this solution is a recipe for disaster and no seems to be listening. So let me frame the problems facing this system with a diagram from the book, Mythical Man Month.
Using the analogy from the book software products start out in the “Program†quadrant and are transformed via generalization, testing, documentation, maintenance, and system integration into a “Programming System Productâ€. The “Programming System Product†in our case is www.healthcare.gov and the final acceptance test is whether the American people can use it to purchase subsidized insurance. In 1974 Mr. Brooks asserted that a “Programming System Product†costs nine times as much as the “Program†so the vast majority of the cost and effort is spent generalizing, testing, documenting, and integrating the interfaces. Unfortunately for Mr. Zients this part of software engineering has not changed over the years.
From the reports I have read there has been very little testing and the specifications for the programming interfaces did not go out until eight days before the launch. It looks like most of the money and effort was spent in the “Program†quadrant and very little was spent in the areas that would actually result in a successful “Program System Productâ€. This reeks of management failure. As part of the 1% who successfully got through the application process far enough to download a copy of my potential insurance plans I can say that the site has a lot of serious problems. It brings a whole new meaning to the term, “bad beta siteâ€. Although I have no doubt that this new contractor, QSSI, can clean up the code discussed in this Reddit thread, the other problems that have been reported are more daunting and time consuming. Here is a short list of problems in no particular order.
- The usability problems pointed out by the NN group
- The back end problems pointed out by Dan on marginal revolution.
- The 834 problems pointed out by Sarah Kliff on the Wonkblog
- Identity theft problems pointed out at MotherJones.
I think both the Affordable Care supporters and detractors agree that despite the fact that the web site is a clusterfark of monumental proportions, it will get fixed eventually. The question is whether it will be sufficiently complete and secure in time. Since they ignored my old web development adage, “copy the best and ignore the restâ€, maybe they should start looking at an exit plan that involves joining forces with the “best in the businessâ€. There is still time for letting www.eHealthinsurance.com and its six competitors finish a smaller, less politicized version of the the job and minimize the impact of a failed www.healthcare.gov.
Cross posted at alazycowboy.com