The further to the left or the right you move, the more your lens on life distorts.

Saturday, November 23, 2013


The New York Times is slowly breaking with it self-appointed role as the Obama administration's chief journalistic protector and apologist, and has begun to do some honest reporting on Obamacare. In an article this morning, Eric Lipton and his colleagues write:
The online [Obamacare] exchange was crippled, people involved with building it said in recent interviews, because of a huge gap between the administration’s grand hopes and the practicalities of building a website that could function on opening day.

Vital components were never secured, including sufficient access to a data center to prevent the website from crashing. A backup system that could go live if it did crash was not created, a weakness the administration has never disclosed. And the architecture of the system that interacts with the data center where information is stored is so poorly configured that it must be redesigned, a process that experts said typically takes months. An initial assessment identified more than 600 hardware and software defects — “the longest list anybody had ever seen,” one person involved with the project said.

When the realization of impending disaster finally hit government officials at the Aug. 27 meeting — just 34 days before the site went live — they threw out nearly 30 requirements, including the Spanish-language version of the site and a payment system for insurers to receive government subsidies for the policies they sold.
For almost three decades I ran a software engineering consulting company, so I've seen lots of failed software projects. They all have the same basic characteristics: unrealistic schedules, hazy or non-existent requirements, poor management bullied by executive management, wasted or misdirected technical effort, a continuing stream of requirements changes, and a poorly designed architecture that often is precipitated by all of the preceding flaws. The Obamacare website is a case study in such failed efforts.

Like the president, I've also written a few books, although none of them are about me. Interestingly, one of my books is the world's most widely used software engineering textbook. After reading the NYT article and many other descriptions of the Obamacare website, I feel safe in stating that no one in the administration in any position of authority every read my book.

In the first edition of the book (way back in 1982), I wrote about software "myths"—things that software managers and practitioners believed about software projects that simply weren't true. Over the past 30 years, reviewers of subsequent editions suggested that I remove my discussion of myths because "everybody knows this stuff." Apparently, not everybody.

I disregarded the reviewers' suggestions, and even today, as the eighth edition is being prepared for publication in January, 2014, the myths remain in the book. Here are a few:
If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept).

If we decide to outsource the software project to a third party, we can just relax and let that firm build it.

A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.

Software requirements continually change, but change can be easily accommodated because software is flexible.

Until we get the program "running" we have no way of assessing its quality.

If you read the NYT article, you'll come to understand that the Obama administration believed every one of these myths. A software engineering train wreck ensued.

In the Preface to the eighth edition of the book, I write:
When computer software succeeds—when it meets the needs of the people who use it, when it performs flawlessly over a long period of time, when it is easy to modify and even easier to use—it can and does change things for the better. But when software fails—when its users are dissatisfied, when it is error prone, when it is difficult to change and even harder to use—bad things can and do happen. We all want to build software that makes things better, avoiding the bad things that lurk in the shadow of failed efforts.
In the case of Obamacare website, the thing that "lurk[s] in the shadow of failed efforts" isn't the website itself, it's the legislative monstrosity that we call Obamacare. It will create havoc and cause heartache as we move into 2014.