Mr. Zients Versus The Mythical Man Month

Last week I had to chuckle when Mr. Zients announced that "by the end of November, will work smoothly for the vast majority of users." I am one of the few long time 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 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.

  1. The usability problems pointed out by the NN group
  2. The back end problems pointed out by Dan on marginal revolution.
  3. The 834 problems pointed out by Sarah Kliff on the Wonkblog
  4. 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 and its six competitors finish a smaller, less politicized version of the  the job and minimize the impact of a failed

Cross posted at

The Mythical Man Month

With the web site problems of dominating the news, I was reminded of the classic book on software project management from my era, The Mythical Man Month. Surprisingly I found out that the first edition is available at I guess it is too late to recommend that someone in the Department of Health and Human Services read it before throwing more people at the project.

Some people might argue that a book written in 1975 is not relevant to today’s project managers. Well, here is a shorter IEEE article, Why Software Fails, written in 2005 that echoes a lot of the same sentiments. If we believe the reporting is accurate then this project has already exhibited many of the factors that should cause the project to fail. Read it and weep! In that article the authors say:

Why do projects fail so often?

Among the most common factors:

  • Unrealistic or unarticulated project goals
  • Inaccurate estimates of needed resources
  • Badly defined system requirements
  • Poor reporting of the project’s status
  • Unmanaged risks
  • Poor communication among customers, developers, and users
  • Use of immature technology
  • Inability to handle the project’s complexity
  • Sloppy development practices
  • Poor project management
  • Stakeholder politics
  • Commercial pressures