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.

What do Buxton’s transition diagrams and La Bohème have in common?

November 12, 2011  |  Uncategorized

They’re not dominated by the States!

Thanks to Marty’s suggestion in class, my project 4 team decided to attend tonight’s showing of La Bohème.  This was my first time at an opera, and I was absolutely blown away by  the experience.  The cast expressed genuine emotions to a beautiful soundtrack.  But like Marty foreshadowed in class: the set was magical.

This week Chen and I revisited Bill Buxton’s lecture on Sketching and Experience Design.  I am a sucker for bad jokes, and Buxton used one that stuck for me: “Q: What do Canada and transitions have in common?/ A: They are both dominated by the States.”  For a good portion of the lecture, Buxton harps on the fundamental importance of transitions in design.  He goes as far as to say “experience happens in the transitions”.  The gravity of this lesson struck me when I saw an iPad adjust its brightness.  I watched the user of the iPad interact with the device and then left it alone for a couple minutes.  In an beautiful way, the fully-backlit screen slowly dims like a candle being blown out in the wind.  But then the moment the user touches the tablet again, the display springs back to life like a fresh match striking its matchbox.

I witnessed the importance of transitions again in La Bohème.  The opera begins outside of a house on a stunningly realistic snowy evening.  As they walk inside, the entire stage rotates like a merry-go-round along with their movement.  When inside the house, a glowing light starts to emanate from the frosted windows of the set.  The light keeps getting brighter and brighter, until you see a woman holding a candle on the other side of the window.  This method is how the main actress is introduced (transitioned into the play).  Before seeing the candle, I thought the inside set was going to be an ordinary, static setup.  But the candle added so much depth to the scene.  The only word that I can describe my feeling of the set is interactive.  The play uses a similar method at the end of act II.  There is a large party in town and you hear the faint sound of drummers.  As the party continues, the noise of a band gets a little lounder and louder some more.  Then a marching band appears gaining the attention of all of the characters in the opera and the audience.  This band then walks off the stage and the curtain drops.  Seconds later, the band marches into the auditorium and out of the room.  During Act III, a very beautiful stage transition happened.  Before the transition the stage is a snowy scene with a gate guarding a courtyard.  The stage rotates 180 degrees to a s (yet again) snowy scene of the courtyard. But halfway into the turn, you see a cutaway of a house where people are eating and drinking in a cozy room.  For those few seconds where I watched the joy in the shelter, I felt warm and happy.  But the stage’s arrival at the frozen courtyard felt even colder because of that brief warmth.

After the opera ended, I have started to wonder what I have been missing out on.  My previous experience with the performing arts have been static scenes with curtain drops in between.  But IU’s production of La Bohème shows that there is another way.  With the rotating stage and other show elements, the entire opera feels like one flowing story.  And it makes me wonder how crazy the storyboards were to achieve such an enormous feat.

All in all, I am exceptionally glad that Marty challenged us to attend the play.  And the transitions of  La Bohème made the opera experience for me.

So What’s the Scoop on “HTTPS” and “SSL”?

April 27, 2011  |  Web 101

The internet is shockingly similar to one gigantic game of Chinese telephone. On the internet, the men-in-the-middle could be your internet service provider, the government, your network administrators, or even somebody else on your WiFi network. If your browser shows http while browsing Facebook, then the information you and Facebook pass back and forth is in plain text that anybody in between can understand. "https" means that you and Facebook scramble the messages to secure your communication. https really means "HTTP using SSL". SSL is the standard way that information is scrambled and unscrambled on the internet.

Read More

Noise Pollution in Shanghai

December 14, 2010  |  China

On a warm autumn Friday morning, Tiger Woods lines up his par putt on the 9th hole.  The green is in beautiful condition despite being early November.  The perfect condition of the course could be attributed to the world-class skill of its grounds’ crew.  Without their tremendous efforts, the golf course would have been unable to attract the who’s who of PGA golf: Tiger, Mickelson, Ells, and more.  The most extravagant European-styled mansions and a luscious green forest decorate the outside of the playing field.   The entire view from the enormous gallery of people following the famed golfers is absolutely breathtaking.  Onlookers watch Tiger approach his ball, which lies about 15 feet from the hole.  He steps up to the ball, getting ready to take the short putt.  What makes this real life scenario exceptional is not its visual imagery, but instead the constant clamor of ambient noise missing from the appearance.  In a game necessitating such complete concentration as golf, honking car horns and droning sounds of motors are completely out of place. If it were not for the distracting clamor, Tiger might have made his putt and I could have fooled you into thinking this golf tournament could happen anywhere in the world.  However, the scene could only take  place in Shanghai, China.

Read More

Bicycles and Automobiles around Fudan University

December 14, 2010  |  China

I am unable to count the times which I have had near collisions while riding my bicycle around Fudan University.   The bicycle path on Wudong Lu is merely a painted path along the side of the road.  Because of the massive quantity of automobiles on the road without a developed system of publicly-accessible parking lots, the bike paths on Wudong Lu double as parking spaces for cars.  While I was riding my bicycle along Wudong Lu on the day of this writing, I was put into a dangerous situation while I was in front of a local hospital.  There was parked Audi car in the bicycle path in front of me, a city bus was approaching me from behind, a bus stop was in front of the parked car, and my bicycle brakes (like the brakes of cheap bicycle in China) were barely working.  The city bus whipped around from behind and drove toward the bus stop.  The bus thus sandwiched me between itself and the parked car with a mere 2 foot gap.  As a result of this, my handlebars just barely missed colliding straight into the Audi’s rearview mirror.  After this near-collision, I still had to swerve my bicycle into the curb and slam on my brakes before hitting the people who were about to get onto the bus, which was now at a complete stop.  I wish that this same type of story was a rare occurrence, but it seems to happen to me on a weekly basis.  Many of my fellow American classmates in Shanghai have had actual collisions with buses, cars, and mopeds while biking around campus.  They still have the destroyed bicycles and scars to prove their stories.
Read More

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.

“Hello World!\n”

June 16, 2010  |  Uncategorized

tl;dr : I discuss the potential awesomeness of my blog.

Read More