“By the end of November, HealthCare.gov will work smoothly for the vast majority of users. . . . Let me be clear: HealthCare.gov is fixable.”

However, over half the allotted time has passed, and the rumblings coming out of the Healthcare.gov project do not give one confidence that Zients’ prediction is on track. President Obama, at his “mea culpa” press conference on Thursday, said:

In terms of what happens on November 30th or December 1st, I think it’s fair to say that the improvement will be marked and noticeable. You know, the website will work much better on November 30th, December 1st, than it worked certainly on October 1st. That’s a pretty low bar. It’ll be working a lot better than it is — it was last week and will be working better than it was this week, which means that the majority of people who go to the website will see a website that is working the way it’s supposed to.

I think it is not possible for me to guarantee that a hundred percent of the people a hundred percent of the time going on this website will have a perfectly seamless, smooth experience.

Lots of hedge words in there, and as he says, “That’s a pretty low bar.”

Jeff Zients, the Obama administration’s point man in the repair mission, joined the daily update for reporters Friday and said there is a top priority punch list – with “50 priority fixes as we enter this week.”

And that doesn’t count the lower priority fixes in what Zients called an “iterative process.”

In the conference call he said the system is getting better – but it’s not where it needs to be.

“We clearly need the system to perform reliably with fast response times at higher volumes,” he said.

The administration is aiming to get the site working smoothly for the “vast majority” of users by the end of this month – but they’ve also noted that “smoothly” doesn’t mean perfect. Zients said he expects “intermittent periods of suboptimal performance.”

Again, lots of hedge words.

The key metric — and what is not being reported — is the find/fix rate, that is, the ratio of the number of new “priority fixes” being found to the number of “priority fixes” being closed (via repair, workaround, or deferral). Unless that ratio is substantially below 1.0 — that is, you are fixing far more bugs than you are finding — your project is not stabilizing. In fact, as I’ve mentioned before, you can easily go into an “oscillation” mode where you appear to be making progress but then suffer setbacks.

Now, back on October 26th, I also described what I would do if put in charge of making Healthcare.gov work by December 1st:

I would swap out the entire ‘Apply Now’ section (and the supporting backend) for a very simplistic information gathering system. This system would gather your information (including your estimated annual income, with no verification). That’s pretty much it. At some time later, the government would then send you — via mail or e-mail — some form of comparison chart or document showing available plans. It would also have instructions to have you call or contact the appropriate insurance providers or your state Medicaid provider directly. The document would also contain the ‘subsidy calculation’, which may be reduced to a simple comparison of your declared estimated income against a chart/formula. This approach should cut out almost all the interfaces with existing Federal systems and with private insurance companies. It would also defer the sticker shock until you got that list of available plans in the mail/e-mail.

We’ve already seen a few techies in a few weeks do something similar to this with Healthsherpa.com, though they don’t even bother to gather information beyond a zip code.

So let’s think about how Healthcare.gov might look on December 1st.

First, the graphical design can pretty much remain as is. That work has been done, it is now very familiar to Americans, and there’s no reason to change it.

Second, one of the critical problem areas for Healthcare.gov has been the user registration system. HHS just this week started inviting back 275,000 users who had problems registering on Healthcare.gov to re-register. No word yet on how that is working, though they are not inviting everyone to re-register at once to avoid swamping the system. Smart move, but it remains to be seen if the software (and hardware) fixes will allow Healthcare.gov to work at full planned capacity. One move — which may already have taken place, given the HHS invitation — would be to swap out the current system for a simpler one, using the same user interface, but with a cleaner and more reliable back end.

Third, another major source of trouble has been (and remains) the federal data hub, used both by Healthcare.gov and the state exchanges to verify information for subsidies. This is one of the most critical and most challenging systems, since the FDH acts, in effect, as a central switching station for Federal data (income verification, immigration status, etc.) between all the exchange websites (state and Healthcare.gov) and a number of Federal agencies, such as the IRS, the Social Security Administration, and the Department of Homeland Security:

To the extent that the FDH can be simplified in scope and functionality, it will help the stability of both the state exchanges and Healthcare.gov. One solution here is to build a parallel FDH interface that looks just like the existing one, but has greatly reduced or eliminated, but more consistent and reliable, functionality behind it. That would buy time to improve the functionality over time.

This, however, presumes that there is a single clean interface into the FDH, and that the 15 state systems that make use of it do so properly according to that interface. I am willing to bet good money that this is not the case. In time-crunch projects such as this one, the tendency is to find quick and dirty solutions to pressing problems, interface protocols be damned. Thus, instead of using the proper sequence of interface calls, you (in effect) cheat and reach behind the facade into the guts of the system. Think of it as popping open the front of an ATM machine to get your own cash instead of using the keypad and dispenser; that makes it easier for you, but it bypasses security and account tracking controls.

This approach can solve short-term problems, but it almost always comes back to bite you in the butt long-term. If this is being done in the state and/or Federal exchanges — and I strongly suspect it has — then the exchange code has become dependent upon internal implementation details of the FDH, and if those change, the exchange code breaks. Remember that there are sixteen different exchanges that are making use of the FDH, so the problem is vastly more complex than simply one client system (such as Healthcare.gov) interfacing with one service system (the FDH). I strongly suspect that each attempt to fix problems in the FDH for one exchange introduces new defects for some number of exchanges.

Finally, there are the scalability issues that have plagued Healthcare.gov and quite a few of the state exchanges as well. As I predicted, and as has been reported, efforts to open up performance/capacity chokepoints have typically just revealed new ones.

Keep in mind in all this that we have never gotten clear consistent information about the architecture (both hardware and software), design (ditto), and source code size of Healthcare.gov and the associated back-end systems. The “500 million lines of source code” originally reported by the New York Times is almost certainly bogus; the “5 million lines of code” that has shown up in several reports sounds closer to reality, though we have no idea how that is divvied up among all the different systems. Regardless, it is a very large system that a very large number of people have worked on. Without rigorous quality assurance controls, including source control management and stringent testing (especially regression testing), then there’s a high risk of the current development team chasing their own tails indefinitely.

If HHS were doing this properly, they never would have gone live on October 1st, particularly in light of the information that has come out about the lack of testing and general system readiness. Post-launch, if they were doing this properly, they would have shut down Healthcare.gov (and by extension the state exchanges) pending a full technical review of all systems and a rational go-forward plan. I fully expected this to happen at the end of this month, but based on the latest comments both by President Obama and Jeffrey Zients, they are not accepting that course either, for what I am sure are purely political reasons and, again I am sure, against all internal and external technical advice (at least from those brave enough to bell the cat).

That’s why I now suspect that Healthcare.gov as of December 1, 2013, to be a Potemkin website: that is, the same glossy interface, but significantly constrained and unreliable functionality, performance, and quality behind the facade. I expect a number of the state exchanges to likewise be struggling, both for their own reasons and because of on-going problems with the Federal Data Hub.

There is still a chance that HHS will do the right thing, and shut all the exchanges down pending a full technical review and redesign; frankly, if Congress can get its act together and send a “Keep Your Insurance” bill to President Obama, he may well ignore his previous veto threat, sign the bill, and use that as cover to shut the website down for redesign and rework. Or it may work the other way: by Thanksgiving weekend, it may become clear that some of the current problems are insurmountable, and that may convince President Obama to accept a KYI bill in order to provide cover for shutting the website down. Or, they may simply push ahead and watch the on-going technical problems continue to winnow out those whom Obamacare most needs to sign up, while those posing the biggest financial drain on the healthcare system continue to push through until they get signed up.

Webster is Principal and Founder at Bruce F. Webster & Associates, as well as an Adjunct Professor of Computer Science at Brigham Young University. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at bwebster@bfwa.com, or you can follow him on Twitter as @bfwebster.