Why Uncle Sam Can't Code

Whether you choose to describe the failed launch of Healthcare.gov as a train wreck, pratfall, or the software equivalent of the Hindenburg Disaster, you have to wonder how the same government that produced the Manhattan Project, the Apollo Program, and Seal Team Six have failed so spectacularly.

It comes down to six principles that are present in every successful software development team, and most other teams, for that matter. Whether coaching a local junior varsity (JV) basketball squad, leading an elite crew into battle, or running the nation's highest visibility software project, our best leaders embody these characteristics in themselves and foster them within their teams.

Transparency: While it's true that software is the result of a process, it also the practical culmination of the combined brilliance of its participants. Like Manhattan, Apollo, and Seal Team Six, great software teams, from coder to CEO, communicate openly, completely, and without hidden agendas. Politics inevitably creep in to any human endeavor, but transparency about the team's goals, priorities, successes, and failures helps to maintain a focus on results, and minimize the impact of negative personalities or hidden agendas. This is easiest to do in a close knit-team with a common background and an intense focus on a shared purpose, often built on a background of shared adversity: Think Band of Brothers, the Miracle on Ice, or Apple/Google/Amazon/Facebook. The difficulty skyrockets with each increase in the number of participants, project complexity, government procurement rules, and commercial interfaces between partners. (For example, see Healthcare.gov.)

Accountability: The best software development teams are driven by accountability that starts with an important, practical item -- the Use Case. In short, what exactly do you want this code to do? Great software includes thousands of use cases, which are turned into feature requirements and eventually are the basis for testing, when an objective party (Quality) asks, "Does this software do what we wanted it to do?" If not, it's a bug, and testing rolls on, but the software doesn't launch until the bug is fixed.

Discipline: In coding, you can't break the laws of Physics and Finance. Code does what it's programmed to do, despite your intentions to the contrary, and customers pay for the value they perceive, not what you tell them. (That's called "Marketing," usually in a scornful tone). The best coders have rock-solid, inviolate processes for requirements gathering and sign-off, architectural planning, coding, integration, testing, and launch. If you ask those teams, "Is two weeks enough time for adequate testing?" you'll be laughed out of the room.

An open mind: Sometimes the best idea is the one that, at first glance, seems most outlandish. If you run a company based on delivering value to the marketplace via software features and you're approached by a coder with an idea to cut six months off the launch of your new version, you're going to listen. If that idea upends a five-year contract to provide services to the Federal government, it's a problem and is unlikely to see the light of day.

Creativity: Software development is a discipline, but within that structure the individual coder, tester, and support staff can apply their own creativity to get things done faster, cheaper, and more efficiently. In the best software development teams, individual coders and teams have a direct financial stake in the success of the product they're chartered to provide. In government, that's a felony.

Executive engagement: Effective executives don't get updates about their team's progress through the local papers or their favorite columnist. In any new endeavor they quickly establish an operating tempo; a rhythm in which monthly, weekly, daily, and sometimes hourly oversight and governance are provided, and tactical decisions are made.

So, all said, we shouldn't be surprised that Healthcare.gov is unraveling. Anecdotal and factual evidence points to a lack of transparency, accountability, and executive engagement: Stories of last-minute changes, minimal testing, and overarching security concerns point to a lack of discipline. The government model discourages creativity and precludes outside-the-box approaches that arise from the type of open-minded approach that drives the great software providers who enable much of our daily lives.

The bottom line: Healthcare.gov, like the autonomous car, is a complex, software-driven, consumer-facing capability. We wouldn't expect the Department of Motor Vehicles (DMV) to successfully develop an autonomous car. Why would we expect Health and Human Services (HHS) to successfully develop Healthcare.gov?

— Dennis Brouwer, President, The Brouwer Group

brookseven 11/16/2013 | 12:24:55 PM
Re: Yes, but... Dennis,

Actually my point was that handoffs, even to legacy systems, can be tackled by modest teams.  What we did is standard HTTPS handoffs with a specialized mechanism that let us do so securely.  One of those handoffs was to our roles database which assigned each type of user a role depending on the handoff. 

This way the frontline code is actually straightforward and any nastiness can be encapsulated in the piece of code that represents the behind the scenes actions.  Now this is a bit more code heavy than one might want but allows for the separation and testing of all the variants.

The challenge with this all is scaling which is why I brought up Amazon.  They are the KINGS of scaling websites up and down.  I would say that the subs that did the works were likely not guys who did this before, and especially at this scale.

As to the California site, it too has problems.  Comparisons work fine, actual registration has been an issue.  As one of those with cancelled insurance, I skipped all this as my current carrier gave me alternatives internal to their company that did not require me to go to the Covered California site.  My research shows the costs of the Covered California plans are very close independent of who the carrier is.  Now with the pronouncements of the last couple of days, I have no idea what coverage I will have.  I had already swallowed the doubling of my costs so for me the uncertainty is just frustrating.


myhui 11/15/2013 | 12:28:41 PM
Re: Yes, but... What about those states that chose to create their own ACA web portal?

Are they all up now? Are they all running smoothly?

Surely, California's ACA portal must be the best one in the nation!
Dennis Brouwer 11/15/2013 | 12:18:36 PM
Re: Yes, but... Sounds like your skills would be useful inside the Beltway.
brookseven 11/15/2013 | 11:54:02 AM
Re: Yes, but... I disagree with your issues as big deals.  I had a team of two build a multi-technology portal with secure hand-offs and roles based capabilities in about 3 months with 2 people.  I owned some of the handoffs and not others. You just have to know that is your job growing in.  The portal was based off of Liferay.

It did not have a big scaling issue as we were not going to have millions of users and so our data and redudancy issues were simpler.

Dennis Brouwer 11/15/2013 | 11:28:44 AM
Re: Yes, but... The private sector can contribute, and health plan comparisions at www.thehealthsherpa.com are a good example.  The question of scale is critical, but this is also stitching together an array of legacy systems.  That's tough to do when you own them (as in a large telcom for example); even tougher when you don't (IRS, Social Security, commercial health insurance providers, independent doctors and hospitals).  An added wrinkle is the need to conform to insurance industry data transfer protocols in the back office, all without violating privacy and security agreements and practices. 
brookseven 11/15/2013 | 11:19:20 AM
Re: Yes, but... My view is much simpler:

1 - They are doing something of this scale, this quickly for the first time.

2 - The normal sub-contractors for the FedGov are NOT experts in this area.

3 - In particular, the folks that do this are NOT in the normal chain of folks that bid on this.

Essentially this is an e-commerce website that requires LOTS of elasticity.  Once a big rush is done this fall, demand for the site will dramatically decline.  I think the real question is why the FedGov didn't just do the right thing and pay Amazon to do it for them.  Pretty much anyone else (Apple maybe?) is probably nowhere near as qualified.

Dennis Brouwer 11/15/2013 | 10:46:59 AM
Re: Yes, but... The question of the consequences in the private sector is very relevant. I can tell you that in the ops reviews I've participated in, language like "it's getting better every day" did not constitute a valid defense. That said, I've also seen the "too big to fail" dynamic play out in the private sector, where because of a combination of executive detachment and inadequate succession planning, management doubles down on a failing leader because they don't have a replacement on the bench.  
sam masud 11/15/2013 | 10:04:58 AM
Yes, but... All great points but you did not mention that top managers need to leave their arrogance and ego at the door--and keep politics out of it. Hardly does a major federal program come in on schedule and budget. Particularly notable in the case of the Obamacare website disaster is Secretary Sebelius's failure to apologize let alone resign. She only got around to apologizing when hauled before Congress. And why did the president not fire her?

What do you think would have happened if this were the web site of a private company and the EVP or SVP in charge of the project screwed up big time...?


Sign In