I Told You So (Healthcare.gov Edition)

So here’s a prediction. When the final story comes out — almost certainly not until after the end of the Obama Administration — what we’ll find out is this:

This was not ready for prime time and everyone technical knew it. It was political pressure that led to it being rolled out. (And remember the Challenger disaster if you think they wouldn’t have responded to pressure.)

What we’re seeing is the development code, probably pushed into the web site at about 11:02PM Eastern Time on September 30.

Most importantly, I will bet cash money that we will eventually find out the government was demanding major changes — like waivers and coverage changes — up to within a couple months of the rollout.

In March, Henry Chao, the chief digital architect for the Obama administration’s new online insurance marketplace, told industry executives that he was deeply worried about the Web site’s debut. “Let’s just make sure it’s not a third-world experience,” he told them. ….

Confidential progress reports from the Health and Human Services Department show that senior officials repeatedly expressed doubts that the computer systems for the federal exchange would be ready on time, blaming delayed regulations, a lack of resources and other factors.

Deadline after deadline was missed. The biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring, according to people familiar with the process. As late as the last week of September, officials were still changing features of the Web site, HealthCare.gov, and debating whether consumers should be required to register and create password-protected accounts before they could shop for health plans.

I’d like to take a lot of credit for this, but sadly, this one was obvious.

Charlie Martin writes on science, health, culture and technology for PJ Media. Follow his 13 week diet and exercise experiment on Facebook and at PJ Lifestyle

-=-there oughtta be a word for that --when one is glad to see a sad prediction come true, and finds oneself in the quicksand right where he predicted it would be when the scoutmaster lifted his bullhorn and announced the troop would march across the swamp.

Another bad sign for those who know--the HealthCare.gov developer who posted a zipped file of source code asking for help on a Java forum [https://www.java.net/forum/topic/glassfish/metro-and-jaxb/jaxb-error-no-element-mapping-exists-when-binding-xml-objects]. It was possibly not even done with malicious intent, but as something the coder had always done to solve homework problems before and never realized they were breaking real world rules. Meaning a) the coder is VERY inexperienced and b) not good at Java and c) only figured this out on September 4 of this year. And as a QA engineer, it is glaringly obvious what got left out to make the deadline. We keep *warning* people about this...

In the software business, there is one well-worn path that guarantees failure...

1. Start with a firm deadline and a vision that is anything but firm. Lofty goals, nothing concrete.

2. Drag your feet on specifying the concrete requirements. Spend lots of time generating paperwork but not answering questions. But whatever you do, don't touch that firm deadline!

3. Start the coding late, and with most questions still unanswered, because "We can't wait any longer!" But don't touch that deadline!

4. Keep changing requirements throughout the development process; and somehow the requirements always get larger, never smaller. But don't touch that deadline!

5. When team members point out how far behind things are, bury their reports. Never admit the problems to higher ups. Of course if you're foolish enough to admit the problems, the higher ups will demand that water runs uphill because they order it to, and you will be on time because they order you to. But don't touch that deadline!

6. To try to do the impossible, force your people into extended overtime. Not the brief bursts of enthusiastic, voluntary overtime that can push a healthy project over the top, but rather months of soul-crushing mandatory overtime that will make them sloppy and unproductive. Those who can, those with the best skills, will find other work. But don't touch that deadline!

7. When higher ups finally realize just how far behind you are, they will insist that you hire more people. As Fred Brooks taught us 40 years ago, this makes the project later, catastrophically so. But don't touch that deadline!

8. When the deadline arrives, everyone knows you're doomed; but some delusional fool will insist on shipping it anyway, hoping for the best, and planning to fix "the few small problems."

9. Because decision makers suffer from the "few small problems" delusion, they keep demanding updates and fixes on short time cycles: hours and days, when they should be thinking weeks and months (and months). This leads to a phenomenon described by Steve McConnell: premature and perpetual convergence. When you try to ship software, you must integrate or "converge" a large number of disparate efforts. All forward progress stops during this convergence. Then if the convergence fails, you must analyze the problems and diverge the pieces to work on them; and again, there is no forward progress during this stage. This convergence, discovery, analysis, and divergence takes time; but since decision makers are in a hurry to have answers NOW, the team is pressured and rushed, and they do a poor job. Then the decision makers demand another convergence almost immediately, leading to a death spiral.

This is a recurring pattern across the industry. It is virtually guaranteed when you start with the deadline first and refuse to move that deadline (or cut features) even as the features are defined late and poorly and are constantly changed.

Your diagnosis is quite correct. One big difference though. When a SW disaster like that occurs in private industry, reposnsible managers get fired, and if its bad enough the company goes under. in gov the managers get promotions, and the agency gets an even bigger budget to fix the disaster. Then the politicians in charge of it all try and tell us that the crashes prove how popular the system is, the MSM backs up the lie, and the low info voters beleive them.

Dont just blame the company. I suspect just as much or more blame goes with the gov managers who tasked them. It sounds like the requirements were constantly in flux, and the gov chose to act as the integration contractor, both extremely bad practices. Having a firm deadline that cant possibly slip, when the requirements it is based on are still changing, is also very bad practice. And aparently lots of people were saying the SW was not ready, but obamas people chose to ignore those reports.

They also missed the fact that these policies are way too expensive for most people, especially when you consider the deductibles. Remember all that whining a few years ago about an extra $12 a month from the social security deduction or whatever, and how people would buy a pizza with that? Now we're talking about hundreds of dollars more per month, sometimes over a thousand more.

I'm amused when reporters are citing a few people who successfully enrolled in policies. Except, we already know that insurance companies need a couple of weeks to process and issue the policies, and the premiums must be paid. And we still haven't seen what will happen when people try to USE the policies they think they've purchased.

This all keeps smelling like a bad insurance scan that arrives on the office fax machine that the BBB has already warned you about.

-=-there oughtta be a word for that --when one is glad to see a sad prediction come true, and finds oneself in the quicksand right where he predicted it would be when the scoutmaster lifted his bullhorn and announced the troop would march across the swamp.

Another bad sign for those who know--the HealthCare.gov developer who posted a zipped file of source code asking for help on a Java forum [https://www.java.net/forum/topic/glassfish/metro-and-jaxb/jaxb-error-no-element-mapping-exists-when-binding-xml-objects]. It was possibly not even done with malicious intent, but as something the coder had always done to solve homework problems before and never realized they were breaking real world rules. Meaning a) the coder is VERY inexperienced and b) not good at Java and c) only figured this out on September 4 of this year. And as a QA engineer, it is glaringly obvious what got left out to make the deadline. We keep *warning* people about this...