Suderman is unsatisfied with the administration’s excuses:
Despite repeated promises that the implementation process was on schedule and the exchange system would be ready on time, it wasn’t. It wasn’t fixed within a few hours, or a few days, or most of a week—even with hours of offline time for retooling. And the massive traffic volume that was supposed to be responsible for the site problems was, at most, only one part of the problem.
So if the administration knew that the problems were due to more than just traffic, and that they would not be resolved in the first week, then they weren’t telling the truth. And if the administration did not know, then that suggests they may lack the understanding or capability to easily resolve the technical flaws with the exchanges. Either way, at this point, it’s hard to avoid the conclusion that the administration is either intentionally misleading people, or incompetent, or both.
Allahpundit worries about the errors that are harder to see:
Eventually, someone in the federal brain trust will figure out how to tweak the site so that it’s capable of processing basic vital information about the enrollee and creating an account for him/her, just like every privately-run commercial website in the world does every day. The hard part, which has already forced some of the state exchanges to partially suspend website operations for awhile, is accurately calculating the subsidies that each enrollee is entitled to under the law. If the coding is so poor that it can’t create accounts for people, how will it handle a higher-end function like that?
Dan Mangan reported late last week that as “few as 1 in 100 applications on the federal exchange contains enough information to enroll the applicant in a plan”:
Experts said that if Healthcare.gov‘s success rate doesn’t improve within the next month or so, federal officials could face a situation in January in which relatively large numbers of people believe they have coverage starting that month, but whose enrollment applications are have not been processed.
Jyoti Bansal, the founder of a company that specializes in keeping essential functions of websites up and running, argues that high traffic was not a good excuse for the problems:
In sites like these there’s a very standard approach to capacity planning. You start with some basic math. Like, in this case, you look at all the federal states and how many uninsured people they have. Out of those you think, maybe 10 percent would log in in the first day. But you model for the worst case, and that’s how you come up with your peak of how many people could try to do the same thing at the same time. Before you launch you run a lot of load testing with twice the load of the peak , so you can go through and remove glitches. I’m a very very big supporter of the health-care act, but I don’t buy the argument that the load was too unexpected.
Tom Lee weighs in:
It is much more likely that Healthcare.gov’s problems are due to more expensive operations related to the insurance application process itself. Checking users’ eligibility and filing their applications requires integration with a separate and more complex set of systems–ones that have little to do with your web browser. Fixing those sorts of bottlenecks can be easy or difficult; the boring truth is that it’s hard to say definitively from outside the system. Much harder than carping about uncompressed Javascript, at any rate.
The Dish 