The economy as (metaphor)

Arnold Kling points us to Paul Rosenberg pointing us to Anat Shenker-Osorio, who notes that:

The dominant metaphor in public discourse is a conservative one – the economy as body – with implications that tend toward passivity and acceptance of whatever ills there may be. The dominant progressive metaphor – the economy as machine, particularly a vehicle – has opposite implications towards action, and taking steps to fight against economic disasters.

I’m not immediately persuaded that either of these metaphors dominates public discourse.  Neither is Kling, who adds:

If the economy is a machine, then perhaps it can be tuned by skilled mechanics. If it is not a machine, perhaps those skilled mechanics will get things wrong. It is not surprising that progressives think in terms of the machine metaphor, while others of us do not think in those terms.

Lately I’ve come to think of “the economy” in comparison to a large software project.  Most people assume that this follows the “economy as machine” metaphor, because software is almost entirely deterministic and created by engineering types.  This assumption is astoundingly wrong, and the fact that it persists among people who commission and manage software projects explains most of the cataclysmic fuckups in computing history.

Lemme ‘splain.

Assuming we’re not talking about crawling horrors from the 1960s, software is composed of small, well-defined pieces at its lowest levels.  Just as I don’t care where my pencil came from or how it was created, the chunks of code I write don’t care where their input comes from or how it was computed. We write software this way to break its complex problems down into manageable chunks.  If I’m writing a webapp, I don’t need to care about how to decode voltage levels on an Ethernet bus into bit patterns, or how to set pixels on the screen of a MacBook Pro; I just need to care about rendering HTML and wrangling HTTP requests.  Similarly, if I’m running a grocery store, I don’t need to care about building the diesels in the container ships that deliver Pocky to this continent; I just care about whether the Pocky I ordered gets to my store before I run out of inventory.

Much like a machine — that diesel, for example — a software package sure looks like it can be designed: like the whole thing can be specified carefully ahead of time by a clever designer and manufactured to precise tolerances by diligent software engineers.  The problem with software design is, again, a problem of scale: the number of components needed is intimidatingly large, and the number of interactions between those components is larger still.  Each of these interactions affects the implementation of each component, and the implementation of a single component often creates new interactions that weren’t obvious at the design phase.  Imagine designing an engine, and discovering that the oil channels cut into the block weaken it at a critical juncture.  You reinforce the block, only to find that the added thermal mass makes your existing cooling system inadequate.  Beefing up the cooling system requires a larger oil pump, which affects the propshaft placement, which means the crankshaft races, which means more changes to the block… and now this relatively simple, century-year-old technology has defeated your ability to design it up-front.  Software is like that, but thousands of times more so, because the interaction between parts isn’t limited by physical constraints.

So while software architects will try to design systems in their heads or on whiteboards before a single line of code is written, real software is designed — in the engineering sense of the word — as it is written, or if you’re lucky slightly before it is written, one component at a time.  Then it gets redesigned when other components upon which it depends are implemented (or themselves redesigned) and the underlying assumptions change slightly.  Maybe the team working on one of those other components figures out how to make it ten or twenty times faster, and you can change your component to take advantage of that new capability.  Maybe there’s a subtle bug in your component’s output that doesn’t manifest itself until those erroneous data have been folded, spindled, and mutilated and passed to a component five or six levels removed from your own, costing weeks of debugging effort.  Software is predictable at the micro level but very unpredictable at the macro level.  Sound familiar?

One of the first — and still one of the best — books to be published on software design is Fred Brooks’s The Mythical Man-Month.  In it, Brooks introduced the proposition that “adding manpower to a late software project makes it later”, which is now known as Brooks’s Law.  The main insight here is that software isn’t produced simply by having N programmers cranking away on their keyboards for T hours until T*N exceeds the complexity of the project.  Programmer time can’t be aggregated into a common pool and reassigned arbitrarily; neither programmers nor lines of code are fungible.  The patterns of interaction between specialized components, and the adaptation of those components to the required interaction, are critical.

Of course, all metaphors suck in one way or another, and this one sucks in the end result.  Software is designed — however imperfectly — and it is intended for a specific use, to solve a specific problem or to implement a specific set of features.  Economies aren’t like that.  You might do your level best to build a manufacturing economy and end up with a service economy instead.  I’m sure there are other limitations.


1 Response to “The economy as (metaphor)”

  1. 1 TMI
    August 26, 2011 at 09:55

    Which begs the question, “What would a pencil do–or look like–if designed by Congress?”

Leave a reply; use raw HTML for markup. Please blockquote quotations from the post or other comments.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

anarchocapitalist agitprop

Be advised

I say fuck a lot



Statistics FTW

%d bloggers like this: