6 Notes To Consider on the Technical Difficulties with Healthcare.gov
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
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:
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/