Posted on by JesterXL

Some Notes To Consider on the Technical Difficulties with Healthcare.gov

I’m not involved. I am not saying I’m for/against ACA. That said, a few things I’ve gleaned from a few of the technical views on the internet that weren’t from a higher profile source such as the NY Times:

http://www.nytimes.com/2013/10/21/us/insurance-site-seen-needing-weeks-to-fix.html

First, when management says “a few weeks”, what that really means is a few months. Yes, months.

Second, because it’s so big with many of the parts not under the purview of the contractor, they can’t rewrite it. That means, it’ll take 2 times or more longer.

Third, bringing on additional contractors/people will not help fix the problem. There was a book written in the 1970’s called the Mythical Man Month that debunked the claim that adding more programmers will make things get done faster. It causes the opposite. See Slate’s coverage here: http://www.slate.com/blogs/moneybox/2013/10/21/obamacare_and_the_mythical_man_month.html

Fourth, launching a site before it’s fully tested is fine and encouraged. Software, currently, has no fool proof way to detect for all problems. There are certainly languages and programming techniques some mathematicians can use, but that’s not the tools the private sector uses to build web sites.

Fifth, even if fixed, it’s clear the parties they’re responsible for connecting to for customer data are a huge component and huge part of the problem such as the Centers for Medicare and Medicaid Services. Since they are not under the direct control of CGI Federal, the contractor originally responsible to build healthcare.gov, there is only so much you can do to compensate for someone else’ incompetence & lack of communication. Meaning, holding CGI solely responsible unfortunately is not an option. It’d be easy to blame CGI for the failings, but that’s not how software, and our bloated government, work.

Sixth, 8 out of 10 software projects are failures, and 9 out of 10 are perceived as failures. Software is hard. We do it not because it’s a lottery, but because when it works it makes a huge difference despite the huge assurance we’ll fail.

Things will slowly improve. There will continue to be glitches, some of which the press may even talk about, a year from now. Jan 1st deadline is unrealistic.

… and for those who are curious about what just 6 million lines of code can do vs. 500 million, check it: http://arstechnica.com/information-technology/2013/10/the-navys-newest-warship-is-powered-by-linux/

2 Replies to “Some Notes To Consider on the Technical Difficulties with Healthcare.gov”

  1. On NPR’s ‘To The Point’, Warren Olney had on a few guests to talk about the implementation (http://www.kcrw.com/news/programs/tp/tp131010when_will_obamacare_). They discussed many of the points you talked about including a few that I thought were really interesting (and a royal nightmare):

    1) The consulting firm & different consultants involved recommended going with a blank slate for the system. There is a lot of +/- for doing this but the scale is increased exponentially trying to tackle a project of this size from the ground up. That and starting fresh also means that there could and probably were a lot of hidden issues that were not thought about until they become more apparent.
    2) Many of the systems, such as Medicare/Medicaid are legacy systems that had to be integrated into the workflow. Some of these systems are built in Cobol, so I can only imagine how complex/fragile the integration points must be.
    3) Many of the States used the federal funding to tackle other outstanding issues & outdated systems at the same time, effectively increasing the complexity and time frame of the project(s)
    4) Much of the system is really a bridge that interacts with 3rd party systems, such as listing the current offers from insurers and then transmitting the form back to them. It sounds like a lot of these 3rd party endpoints came online late in the game and having to stitch them all together was probably a last minute scramble.

    Fundamentally, this sounds like a nightmare project in complexity and scope without all the other issues such as bureaucracy, red tape and other guidelines that occur when working in governmental projects. I definitely have a lot more leaway & understanding for the people behind the system, but only because I have been there and know how projects like this work.

Comments are closed.