Inside the race to rescue a health site, and Obama

Towards the end of October they got "fired" from this role and replaced with QSSI ... who are responsible for the "data hub" and this Oracle EIDM system (which is part of the data hub? Development has been so politicized that they refused to publish architectural diagrams, not even supplying them to the state exchanges).

Government workers have interesting employment metrics. They are, for lack of a more profound term, extremely risk averse. If you, as a contractor, propose a new solution to an existing problem, you are looked at like a watch practitioner, or perhaps a voodoo doctor. All claims are treated with a level of skepticism that can only be described as paranoia and sadly, given the general trend on government projects, that isn't necessarily unwarranted.

Building a website to service a total user base of 30,000 users is, for most of us I'm sure, pretty easy. That's not exactly a difficult scaling target to hit, and could easily be done on commodity hardware. However, in implementing something similar, I was forced to order 4 Sun Fire boxes, at a cost of over $10k each, to mitigate concerns of speed.

Certificate based SSL is also very easy, but we were coerced into purchasing a dedicated SSL module to offload SSL handling to hardware, to mitigate concerns of security, which were then compounded by anecdotal experience that "ssl is slow". So, not only did we have to implement SSL-only for a site with absolutely no public facing endpoint, we had to do so with hardware crypto, that we had to hustle to learn at the last minute -- all reasonable sounding objectives, but compounded with the notion that the contract was a firm-fixed price, bid with different hardware and software SSL, and you can see where the project was trending towards either failure, or a lawsuit after an overrun.

The phases of a government contract too, are curious. It starts with skepticism, in which everybody wants the project to die before implementation because its public failure would make everybody look bad, then, if it's somehow able to assuage enough fears to get a go-ahead, you're generally assigned a COTR (Contracts Officer) that ostensibly wants the project to succeed, but would happily wager a failure before implementation than a bigger failure post-implementation.

Assuming you can get to the point of actually convincing somebody that the project might actually succeed, and then it might actually deliver good results, the exact opposite happens -- EVERYBODY wants to become a stakeholder, so that they can have their names attached to the success. This has its own faults, because now everybody wants to put their stamp on the project -- which means week-long meetings with various groups of stakeholders all arguing over what image should be used in the page header -- I've had day-long meetings in which the only topic of discussion was "In the picture of the building, the summer photos have too many leaves on the trees, and we can't see the building, but in the winter photos, there are too few leaves, making the scenery look dead... how do we fix this?"

Assuming your project hasn't failed yet, you get to a point where now, all the other contractors in the building hate you, and want you to fail. In a normal business, that would never be an issue -- but in the government, the DNS changes are handled by company A, while the active directory is managed by company B. You're sitting there, company C that you are, requesting changes from company A and company B -- both of which will happily obey the exact letter of every request, so that they can indicate full compliance, but which are happy to interpret those letters in such a way that set you up for failure, so that if the project is at this point, you've gotten to the level where the idea is sold, and failure can be blamed on the contractor -- YOU! This means that if it fails, Company A and Company B will swoop in with the exact same idea, only they'll offer their superior experience and intimate knowledge of the project, its failures, and the existing infrastructure to why the project will succeed in their hands.

This should be a blog post -- I'll shut up now.

"...the root causes for these site flaws to be hundreds of software bugs, insufficient hardware and infrastructure."

The infrastructure flaws cannot be chalked up to "not learning it well enough"....There is no database - not Oracle, not PostgreSQL, not MongoDB....and not MarkLogic - that would have handled the traffic on this hardware and infrastructure.

Am I parsing that incorrectly?

"Prescription drug coverage" has always covered prescription drugs, in my experience. I've never had a policy that would (to my knowledge) cover OTC meds.

... And actually, I completely reject your characterization of it as a wealth transfer. It's insurance. You have no idea if you're going to need it. You may be in a car accident and badly break your legs, and require corrective surgery and rehab. You may get pneumonia or a bad MERSA infection. If you haven't saved up a few hundred thousand dollars and you show up at an ER, then the wealth transfer is to you when the hospital eats the cost and passes it along to properly insured people. That's not even going chemo/surgery should you develop cancer, god forbid.