Media admits: if Obamacare isn't fixed in one month, 'panic' will ensue

Friday, October 11, 2013 by Mike Adams, the Health Ranger Editor of NaturalNews.com (See all articles...) Tags: Obamacare, bug fixes, panic

---

(NaturalNews) The mainstream media is reluctantly coming around to the reality that the Healthcare.gov Obamacare exchange is fatally broken. At the same time, the media is also pushing a new story that claims mid-November is the "new deadline" for fixing what they call "Obamacare glitches." See Reuters for an example.

The media is, of course, just as delusional about Obamacare as Obama worshippers themselves. Consider these three points:

1) The media is lying to you when they describe the problems with Healthcare.gov as "glitches." In reality, the website suffers from disastrously failed computer code, critically flawed architecture and an astonishing lack of quality control testing. These cannot be fixed with "patches" or "updates" as the media is pretending.

2) It is now abundantly clear from my code analysis of the client-side Javascript that Healthcare.gov needs to be scrapped and redesigned from the start. That is at least a three-year project. Fixing the current code would probably take 3 - 5 years. Yet the absolute hard deadline for all this working is less than 3 months away: January 1, 2014. There is zero chance it will be fully functioning by January 1, 2014.

3) As a result, the IRS will be fining Americans for not purchasing a mandatory insurance product which they are unable to purchase because the government-run exchange system is broken. This is, of course, the epitome of failed government, reaching Orwellian heights of absurdity.

People will "panic" if it's not fixed

Reuters quotes the chief executive of a health insurance provider saying, "As we get closer to January 1st, if in fact some of these glitches are not fixed, then I think people will become more and more concerned, and maybe panic about it."

This person, too, is delusional about the real status of the computer code underlying Healthcare.gov. He believes the site merely suffers from a few "glitches" which can be "patched" in a month or two. He does not grasp the reality of just how disastrously broken the Healthcare.gov code really is.

Nor does HHS secretary Kathleen Sebelius, who continues to defend Healthcare.gov, calling it "functional" and somehow claiming people are signing up through it even though the White House refuses to release any numbers of how many have actually been enrolled. That number is widely believed to be less than 10. (A few thousand have reportedly been signed up through state-run exchanges like the one in Kentucky, but Healthcare.gov, which powers 36 states, can't name a single person who has successfully signed up.)

Of course, I can't expect Kathleen Sebelius to understand computer code. She's not a programmer. Nor are mainstream media journalists. Nor are health insurance company executives. Because they have no training in large-scale IT projects, they have no qualifications to examine computer code and make a determination about its status. So they believe whatever the contract programmers tell them, and contract programmers are often wildly optimistic about the status of their own code, even when they're trying to tell the truth.

How IT (Information Technology) projects really get developed

It is not usual in the world of IT development for a project to take ten times longer than originally estimated. A team of programmers might tell you, "This will take a month!" but you find yourself still testing the code ten months later.

I grew up surrounded by PARS programmers who wrote the computer code running the airline reservation systems throughout the 1970's and 80's. PARS stands for Programmed Airline Reservation System, and it was up and running long before Windows, long before the Internet, and long before languages like C++ even existed.

The airline reservation systems installed at airports and travel agents, everywhere around the world, all talked to a central reservation system via direct communication lines that operated no faster than a 4800 baud modem. That central reservation system, although it was a multi-million-dollar computer system, was orders of magnitude less powerful than any off-the-shelf PC you might buy today. Yet it had to handle hundreds of real-time requests every second from all over the world: new seat reservations, cancellations, stand-by passenger fulfillment, air route schedule changes and more.

If the PARS system went down, the entire airline went down with it. You can't run an airline without a real-time reservation system. So airlines hired the best and brightest programmers in the world to design, build and maintain these systems. My dad, who also did R&D work for numerous companies (including Pfizer at one point), was one of the PARS programmers who helped keep airlines like TWA and Qantas Airlines (Australia) up and running.

These people wrote incredibly tight, intelligent computer code. They had to, as there was no room for "bloat" in the system. Any critical failure could bring down the entire airline and cost it millions of dollars every day in lost revenues. So PARS programmers became the best of the best. Many of them went on to design the real-time systems running American Express transactions, for example, or banking institution systems.

Every PARS programmer knows that the keys to a successful large-scale IT project include:

1) Fully understanding what the system is supposed to actually DO (i.e. what behavior should it produce?) when it is completed.

2) Creating the correct underlying data structure to support the desired functionality.

As a simple example, if you want the system to have a working search capability on a person's name, you would want to make sure the underlying database has the name fields indexed in the database. Otherwise, search functions could take 1,000 times longer than you want them to.

If you want a system that's going to handshake with remote databases and accomplish cross-database functions such as INSERT, UPDATE, DELETE (all common SQL functions), then you need to design a system from the start with the correct data types across all the databases that are going to handshake.

You also need to decide on a common data structure format for the handshaking. A common modern-day format is XML. Back in the days of PARS, they simply used byte offsets where they knew in advance that the customer name, for example, begins at byte position 64 and ends at byte position 96.

One of the problems with Healthcare.gov is that it must interface with legacy databases across the government, including social security, Medicare, veterans' records, etc., and then cross-reference that with banking system records, employer records and so on. This task necessarily means navigating hundreds of incompatible databases and trying to "normalize" data across them all for logical decision-making.

If you took the most experienced programmers in the world, even they would be hard-pressed to make such a structure actually work. Yet Healthcare.gov was obviously programmed by inexperienced developers -- people who utterly lack the needed experience to understand the structure, functional complexities, data translations and other challenges inherent to such a complex system. As a result, there is almost no possibility that they can ever make the system work as intended.

Now here's the really important point in all this:

When government IT projects go bad, how does government solve them? It throws more money at bad programmers and hopes for the best.

Throwing more good money at bad programmers doesn't result in clean code

Government is stupid. And when government finds itself far down the road of a disastrous project created by incompetent programmers, it always does the same thing: Throw more money at the problem and hope for a different outcome! (This is, of course, the definition of insanity.)

If IT problems could be solved by throwing money at them, then programmers would rule the world. But they can't. And there's an old joke every programmer knows which goes something like this:

What Management believes about programmers: If one woman can create one baby in nine months, then nine women can create one baby in ONE month!

The moral of the joke is that IT projects take a certain gestation amount of time regardless of how much money you throw at them. You can't cut R&D time in half by doubling the programmer staff. This is a truism about all IT projects, and it has stood the test of time over decades of project development.

This is why Healthcare.gov has zero chance of being fully functioning by January 1, 2014. The critical failures it is exhibiting are indicative of the kind of problems they will require YEARS to fix, not weeks. Even throwing a trillion dollars at the problem will not magically clean up the failed design and incomprehensible code that's now causing the site to crash when anyone tries to use it.

Obamacare must be scrapped

Every R&D project reaches a point of confusion beyond which it is actually cheaper and faster to scrap the whole thing and start over. It is my belief that the Obamacare system has already passed that point of no return, and that it would be faster and cheaper to scrap it and start over from scratch. The actual development life cycle on such a system should be something around five years if you really want to get it right.

Or, better yet, you could just scrap the whole failed Obamacare system and let people and companies buy their own health insurance without disastrous government interference.