An entrepreneur’s retrospective on HealthCare.gov

Rustam Lalkaka, Co-founder of Anapsis

Gallons of ink (pixels?) have been spilled on what went wrong with the rollout of healthcare.gov. As a software engineer who has spent time working on both sprawling, mission-critical projects at Microsoft and building healthcare-focused SaaS at Rock Health-funded Anapsis, here are my two cents.

To draw a bastardized analogy between software development and civil engineering:

1) The White House and Congress have decided we’re going to build a new interstate highway system.
2) It’s going to be ready on October 1st, 2013.
3) All cars are required to use the new roads on that date.
4) An agency that has never before managed a large scale physical infrastructure project is handling the general contracting.
5) Construction is bid out to a firm that is talented in the art of government contracting, but just so-so with the process of building roads.
6) No one really understands how the legacy on/off ramps the new system is supposed to interface with work or how they were built. The engineers decide to wing the integration.
7) Because the road construction is (inevitably) late, there’s no time to try all the different route and merging combinations before October 1st hits.
8) The bureaucrats tasked with oversight don’t know how to drive, so none of this sounds all that concerning.

October 1st rolls around, but the way the lane lines have been painted, only 40% of the legally obligated drivers are able to put rubber to road. The president apologizes for the traffic jams. A “tech surge” happens, which just means they find anyone who knows how to use a paintbrush. The lane markings are fixed, but now they realize that 6% of all the ramps are oriented backward, something that can’t be fixed overnight. Everyone gets fired and congressional committees start waving pitchforks.

This would never happen, of course. Politicians-at-large understand that large scale physical capital projects are something to tread carefully around — schedules and budgets are likely to slip and concrete will crack. There’s huge political risk involved. Complicated software engineering projects are no different, but because they’re less tangible and more magical, policy wonks don’t think the classic caveats apply.

The core problem at the Dept. of Health and Human Services, or the numerous contractors they hired to build the site, is a lack of strong tech talent, not malfeasance. The government’s inability to hire top-flight talent is not a question of pay or perks, but about prestige and fulfillment (witness the hordes of startup founders forgoing stable employment and market salary to try their hand as an entrepreneur). As a lawyer, it’s not ridiculous to go work for the government as part of your career lifecycle — a high-profile judicial clerkship is one of the most prestigious things you can do out of law school. If one of my high performing techie friends told me he was going to go work for the Center for Medicare & Medicaid Services (CMS), I would think he was insane.

Without technically adept people in government positions that matter, Sebelius, Pelosi & co. are left to believe that software is magic, and software engineers are alchemists that transform pizza into perfect working code.

You don’t need great engineers building the thing; good will do. But you do need someone who speaks software, and speaks it fluently, managing all the moving pieces involved, someone who can call out contractors when they say integration testing is going to be pushed to the week before launch.

Presumably that same person could have told those drafting the Affordable Care Act (ACA) to a) tranche the user population required to enroll b) stagger invitations or enrollment deadlines. Gmail was in beta for five years prior to general availability. Having all of America beating down the door to Gmail, Dropbox or Facebook on day one would have caused any of them to fail spectacularly.

Comparing ACA software to the Instagrams and Dropboxes of the world actually does the HealthCare.gov developers a big disservice. Each of those it-kids were at a huge comparative advantage compared to HealthCare.gov — they were starting from scratch. Greenfield development is orders of magnitude easier than trying to solve crazy extract, transform, and load (ETL) problems involving mainframe data backends and transaction flows that haven’t changed in forty years. Take a look at Stripe’s API doc, and then look at the CMS doc on 834 transmissions to insurers. Which would you rather code against?

All this paints a dreary picture of the government’s technological competence and its ability to deliver complex technology projects. All is not for naught. Kurt DelBene, recently hired as HealthCare.gov czar, is a skilled technologist and operator (and someone I worked under during my stint in Redmond), and the kind of person the government will have to attract more of in the short-term and develop from within in the long-term. The HealthCare.gov debacle has opened policy-maker’s eyes to the intricacy and risk involved in writing software.

The site’s biggest legacy will be the way it changed the way the government thinks about software, not the debacle surrounding it.