On Build and Analyze this week Marco Arment talked about the U.S. healthcare system, the gradual expansion of forms of state-sponsored coverage, and his general support for Obamacare. Not a topic you might expect to hear covered on a show that is ostensibly about software development and rather involved ways to produce a cup of coffee. But Marco runs his own business and thus needs to face the question of buying health insurance for himself and his family, together with the expense of offering benefits to any employees he might consider taking on. It’s obviously an important problem for American software developers in their capacity as businesspeople as well as citizens. Listening to Marco talk about the topic, it struck me that the political question of healthcare in the United States should be intuitively accessible to software developers in a different way, too.

The U.S. system of employer-sponsored healthcare provision is iTunes. It’s complicated and overburdened; it wasn’t originally designed to do most of the things it now does; in fact, at the outset its design wasn’t really thought through at all (there wasn’t time); many of those involved backed it as a distant second-best solution—better than nothing, but not nearly good enough. Over the years, new features were shoehorned into the basic structure. New problems and inconsistencies emerged and were partially patched. And, inevitably, groups who did pretty well out of the system emerged and entrenched themselves, too. In situations like this, some reforms are possible around the edges, but it’s clear to most people that real structural reform is needed. The people in charge of it come to face a dilemma familiar to both software developers and policy makers. In the words of a Swiss official quoted in an old study (by Ellen Immergut) of the politics of health care in Europe, “Were it necessary to draft a health insurance bill today, I would never come up with the insane idea of proposing our current system.”

As every developer knows, ripping out an established codebase and replacing it with something better is far easier said than done, especially when it’s huge, and a lot of people are doing quite well from it. Perhaps worst of all—and maybe most similar of all, too—the problem has three jointly unpleasant characteristics: it’s really important for the future; a great deal of political fighting is needed to achieve any real reform; and the details of the required changes are eye-glazingly dull, except perhaps to a small number of odd people and parties with a stake in seeing the wrong thing happen.

It’s best not to push this analogy any further. You can already hear it creaking. Sociologists and political scientists who study institutions and policy discuss these issues under the general rubric of “path dependence”. Engineers have their own more or less formalized lore (in books like The Mythical Man Month and concepts like “Second System Syndrome”) that touch on some of the same issues. In the end—some common nerd fantasies notwithstanding—politics is not simply a matter of engineering. Indeed, the lesson taught by everyone from Fred Brooks to Michael Lopp is that—some common nerd fantasies notwithstanding—often even engineering isn’t simply a matter of engineering. But many software developers know what it’s like to inherit a huge, messy, live codebase that does something very important in a really terrible way. And that’s why the U.S. employer-sponsored healthcare system is iTunes.


Note: If you want to learn more about the guts of health care reform, I recommend two books by one of my teachers, Paul Starr. The first his is magisterial The Social Transformation of American Medicine, which takes the story up to the late 1970s. It is the definitive account how America reached the point where its health care system was in structural crisis. His recent Remedy and Reaction is shorter (though it still provides a good historical overview, including the failed Clinton-era reform which Starr himself was involved in) and concentrates on where we are now.