Wednesday, October 30, 2013

Why is Obamacare crashing?

Here's why.

Now from a comment left at a site called Marginal Revolution by a certain Dan Hanson (h/t: Powerline blog, who [following an incorrect link at the MR site, wrongly credits the comment to Dan "Weber"]), there emerges clarity about the fatal flaw behind Obamacare. For the site to be able to give the would-be purchaser of insurance accurate pricing information, it first has to connect with a series of government and private servers:
The real problems are with the back end of the software. When you try to get a quote for health insurance, the system has to connect to computers at the IRS, the VA, Medicaid/CHIP, various state agencies, Treasury, and HHS. They also have to connect to all the health plan carriers to get pre-subsidy pricing. All of these queries receive data that is then fed into the online calculator to give you a price. If any of these queries fails, the whole transaction fails.  
Most of these systems are old legacy systems with their own unique data formats. Some have been around since the 1960′s, and the people who wrote the code that runs on them are long gone. If one of these old crappy systems takes too long to respond, the transaction times out.
In other words, the Obamacare site crashes because it can't get timely responses from some of the much older computers serving government agencies, which use completely different code, data formats and processing. So fixing the Obamacare site will actually mean fixing the older computers? Others at the MR site suggest that one can incorporate "timeout" failures into the coding, requiring purchasers to check back in later, but Mr. Hanson says that will not solve the main problem:
When you even contemplate bringing an old legacy system into a large-scale web project, you should do load testing on that system as part of the feasibility process before you ever write a line of production code, because if those old servers can’t handle the load, your whole project is dead in the water if you are forced to rely on them. There are no easy fixes for the fact that a 30 year old mainframe can not handle thousands of simultaneous queries. And upgrading all the back-end systems is a bigger job than the web site itself. Some of those systems are still there because attempts to upgrade them failed in the past. Too much legacy software, too many other co-reliant systems, etc. So if they aren’t going to handle the job, you need a completely different design for your public portal.  
A lot of focus has been on the front-end code, because that’s the code that we can inspect, and it’s the code that lots of amateur web programmers are familiar with, so everyone’s got an opinion. And sure, it’s horribly written in many places. But in systems like this the problems that keep you up at night are almost always in the back-end integration. 
The root problem was horrific management. The end result is a system built incorrectly and shipped without doing the kind of testing that sound engineering practices call for. These aren’t ‘mistakes’, they are the result of gross negligence, ignorance, and the violation of engineering best practices at just about every step of the way...
"Horrific management" does not begin to describe the problems with Obamacare. They began with a bill that was passed solely by Democrats in Congress, in violation of the rules and without any opportunity to read what was in it, and that had been drafted mostly by the lobbyists for, among a myriad of special interests, Big Insurance and Big Pharmaceutical -- who wanted to ensure that their clients would gain, and not lose, from the politically popular (but financially very costly) changes being made in coverage requirements.


And they are not fixing this in a few weeks.


No comments:

 
Who links to me?