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