The HealthCare.gov “Obamacare” website launched, as scheduled, on Oct. 1, 2013, despite a government shutdown that began that day. As people anxiously seeking affordable healthcare fired up their Internet-connected computers and traffic quickly increased to the website, visitors attempting to enroll soon encountered delays and technical problems.

Moreover, some people who thought they had enrolled successfully in Obamacare using the site were later informed by insurance providers that some necessary information had been lost in the back-end of the system. By December 2013, it became apparent that a third of all October and November enrollments had been lost.

All of these problems led to a “tech surge” rescue operation, announced on Oct. 22, 2013. A team of America’s top engineers and programmers from Google, Red Hat, Oracle, etc., descended on HealthCare.gov and started re-engineering the site, their many tasks miraculously performed while the site continued to run and people kept signing up for health insurance.

So what went wrong? Well, just about everything. Let us count the ways:

There was an unrealistic time frame. Programmers needed perhaps three or four times as much time as was allotted, not just for programming, but the all-important testing phase, too. There was no time for beta load testing or a methodical, phased rollout.

The front and back ends of the site were principally developed by two different companies, Development Seed and CGI Federal (a subsidiary of CGI Group), respectively. Both contractors appear to have different development philosophies and communication between them during the development process does not appear to have been entirely optimum.

Too many other contractors were involved, such as Quality Software Services Inc., a UnitedHealth Group Inc. unit; and the credit-checking organization, Experian PLC.

Too many middle managers were involved with too many different items.

The Affordable Health Care Act (better known as Obamacare) was too big and complicated for any of the managers or programmers to quickly and fully grasp all of its business requirements.

People couldn’t peruse various health plans without first creating an online account, which led to a glut of signups. Furthermore, information-passing between system components was defective, preventing the creation of many accounts.

Astonishingly, Healthcare.gov has no conventional database of user information. It merely writes the User's Name and Password and notes if the user's personal data has been verified. The system checks the person’s purported identity using a registration tool developed by QSSI in conjunction with information provided by Experian. The system then determines eligibility for financial help by sending the verified information to the system’s “Data Hub,” also developed by QSSI. But even here the data is not saved in a database of its own! Because of the fear of assembling a single, logically structured, all-knowing database (you know, like the one the NSA has probably had running since the days of vacuum tubes <grin>), the system instead determines a person’s eligibility by accessing dozens of separate systems of varying type and sophistication scattered all over the place (U.S. Treasury, Medicare, Social Security, Health, Insurance Companies, etc.)

Normally, reading data is less resource-intensive than writing it, but with so many communications links, protocols, interfaces, and secret electronic handshakes, system efficiency inevitably plummets and security/privacy concerns actually increase. A chain is only as strong as its weakest link. Indeed, on Oct. 2, 2013, a major data traffic bottleneck was detected in the registration process involving the Oracle Identity Manager, which was tied into the Center for Medicaid and Medicare’s Enterprise Identity Management system.

Thus, Healthcare.gov was not just a single big system, but the world’s largest multi-system integration project — which inevitably brings to mind the phrase, “pending disaster.”

Even if the person made it through enrollment, the system had to send what are known as 834 transaction forms to each insurer identifying who enrolled that day. Some of the 834s were missing, duplicated or incorrect information apparently appeared on them, thus confusing the insurance companies.

Ironically, the front-end developer, Development Seed, used an advanced, ingenious, static HTML file approach employing the well-known Ruby programming language and a development tool called Jekyll. The static files are served out via the highly scalable Akamai cloud platform — that should have resulted in a front-end able to handle any kind of traffic thrown at it. From what I’ve been able to make out, however, the more mysterious back-end marketplace appears to be written in good old lumbering Java, the COBOL of the 21st Century.

In retrospect, I suppose we should all be amazed that the Healthcare.gov functioned at all on Oct. 1, 2013. The Dec. 22, 2013 New York Times recounts one study revealing that 40 percent of federal contracts have failed compared to a mere 4.6 percent that succeeded. And more than 50 percent of such projects have proved "challenging."

So much for “private-sector efficiency!”

Richard Grigonis is an internationally known technology editor and writer. He was executive editor of Technology Management Corporation’s IP Communications Group of magazines from 2006 to 2009. The author of five books on computers and telecom, including the highly influential Computer Telephony Encyclopedia (2000), he was the chief technical editor of Harry Newton's Computer Telephony magazine (later retitled Communications Convergence after its acquisition by Miller Freeman/CMP Media) from its first year of operation in 1994 until 2003. Read more reports from Richard Grigonis — Click Here Now.