Lessons from HealthCare.Gov


Lessons from HealthCare.Gov

November 22, 2013  |  Development

I simply cannot fathom the technical hurdles involved with building thousands of integrations to ancient, pre-XML, proprietary interfaces that were developed in COBOL 30 years ago that I assume to be common in the insurance industry. Apparently few architects involved in the HealthCare.Gov debacle did either.

Elise Hu recently shared McKinsey & Co’s assessment of the system development progress that was delivered back in March.  This report fully foreshadowed the failures of a system that accepted only six American enrollments on day one despite the $600M price tag.  Oops.

Here is the fun part of the political game: where does the finger point?

Republicans are blaming Democrats.  Democrats are blaming Republicans. Some politicians are falling on their own sword.  Government is blaming the contractors.  Contractors are blaming the government.  This he-said-she-said is just another day in Washington.

The interesting blame being thrown around, especially in Hu’s case, is the employment of waterfall over agile project lifecycle as the culprit.  The assumption in Hu makes is continuous testing inherent in agile methodology could have identified roadblocks earlier in the delivery process and allowed CGI Federal a better chance of overcoming those hurdles.  Hu blames the method of project management for creating such a catastrophe.

I have a gut feeling that most in the tech community want to point a finger at the waterfall methodology.  The waterfall product delivery life cycle leads itself to bloated timelines, massive budgets, and general waste.  Waterfall methodology also tends to segregate business need away from difficulty of feature implementation.  This is a very key point that needs to be addressed with a Lego analogy.

Let’s say that Charlie, a 4 year old with an insufferable need to play with toys, wants you to build him a model car out of Legos.  He loves red cars. And his birthday is tomorrow.  You ask him whether he has any red Lego bricks to use, and Charlie says yes! He brings you his toybox full of Lego’s, and you promise him that you will build him the best red sports car he’s ever seen. You just made Charlie’s day.

You go back home, and rummage through all of the Lego’s determined to build him the red sports car of his dreams. After 20 minutes, you look down at the glorious pile of red pieces. Every red piece he has is a fence! You cannot build a car with those!

You falsely assumed in Charlie’s case that he would have a wide variety of red pieces that you could use for his car.  Your analysis of the situation prior to promising Charlie a new toy was wrong.  Now you need to either buy new Lego’s or spend a long time trying to make the red fences work.  Both of these options add cost and time to an otherwise simple project.

The analysis team of a waterfall project has an enormous task with high risk to make the proper assumptions. Many solution architects would agree that an agile approach around a unified service layer would have been a solid technical approach to solving Healthcare.Gov’s requirements, Hu’s argument. The agile approach could have taken project risk off of the complexities of individual integration points with insurance vendors. But what is missing from the whole picture is the thick line between the sales process and the delivery process of an engagement: the promise and the creation make progress at the other’s detriment.

I believe the real problem may be the relative ease of writing waterfall contracts versus agile contracts. Even empirically proven wrong, the perceived risks of an agile project in contract negotiation are much higher. Big consulting companies like multi-year waterfall contracts that allow for steady income quarter to quarter. And clients like the cushy feeling that they have negotiated for every feature when they sign the dotted line; they also have the ability to sue if a feature is not met. In the case of a government client, the relative ease of contract writing may be multiplied by a billion. I truly hope we can find a way to do this better.

Disclaimer: All thoughts expressed are mine alone, and do not reflect the views of any employer or client.

Scope in Javascript

November 23, 2010  |  Development

We all have those “oh…that makes sense” moments in software development.  Just after you learn something new when you feel that you must’ve only had half a brain the day before because you just couldn’t grasp a concept.   Well I’ve been hoping for that day to come with one particular frustration: scoping in Javascript.  And it finally has.

After reading http://skilldrick.co.uk/2010/11/a-brief-introduction-to-closures/ which linked to the more concise reference http://www.mredkj.com/tutorials/reference_js_intro.html#scope, the moment of clarity came.

Apparently, my frustrations with scope in Javascript was simply a misunderstanding of the var keyword.  Before this revelation, I didn’t really think the var keyword was that important.  I thought it was a way for programmers to say, “This is a new variable that I’m creating.  Not a reference to a pre-existing one”.   Oops.