Wednesday, February 14, 2007

Scaling Socialism

One of the more frequent and fatuous arguments made in defense of socialism is that "it's never been tried in its pure form." As someone who was born and raised in the only major American city ever run by the Socialist Party, I believe that that assertion is demonstrably untrue. Whatever socialism's pure form may be (Marxism? Bolshevism? Trotskyism? Marxist-Leninism? Maoism?), it has been tried and retried again and again, and always with the same result: in the end, the people vote with their feet. Even at extreme risk to their very lives (and I speak now as someone with living relatives in the former East Germany), once people get to experience the true joys of life under socialism, they usually run from it, often while screaming. Why?

I think the answer here is that socialism does not scale. Getting technical for a moment, scaling problems are something we run into often in the supercomputer trade. Sometimes a scaling issue means that a program which works brilliantly with a small and carefully selected data subset fails miserably when used with the larger real-world data set. More recently, it's come to mean that a parallel process that works well with a small processor population actually gets less efficient as you increase the processor count. This is not really that uncommon; with the exception of very special code written to solve very specific cases, as you add processors, most parallel programs eventually find a natural limit beyond which adding processors only increases overhead and power consumption without actually accomplishing more work. In some extreme cases, though, performance can take a sudden and dramatic plunge when you cross some previously unsuspected threshhold.

I believe socialism suffers from the same problem. People easily and readily form small ad hoc groups that operate along socialistic principles, with individuals willingly sacrificing their egoistic interests for the good of the group. But when you attempt to extrapolate from these small and carefully selected data sets and scale socialism up to govern large populations, you run headlong into The Tragedy of the Commons — or as Aristotle put it, the principle that "That which is common to the greatest number has the least care bestowed upon it."

"The Tragedy of the Commons" is an idea most often encountered in an ecological sense: if something is owned by everyone, it's owned by no one, and the question of maintaining it becomes S.E.P.1 You can see this at work in small scale in every city park, bus shelter, or vacant urban lot, and in large scale in, say, the way we treat the oceans. But the principle also applies to factories, cities, cultures; pretty much any human endeavor. It's easy to feel a mutual responsibility to and dependence on people you know, interact with, and are related to. Those feelings taper off with amazing rapidity when the lines of relationship are expanded in either the X, Y, or Z dimensions, to include people you don't know, have never met, and know that you never will meet. Companies with geographically distributed operations wrestle with this all the time — it's darned difficult to make a worker in Chicago feel responsible to a manager in Blue Bell, Pennsylvania — and the problem is only amplified when you tell the workers that they "own" the company.

Try to actually implement the idea of "from each according to his abilities, to each according to his needs," then, and you'll quickly find that a sizable proportion of your fellow proles have decided their ability to show up for work on the Yugo asembly line sober on any given day is only about 50%, while their needs approach infinite.

The issue of scaling extends into the fourth dimension, as well. For example, just this week I learned about a program that could be expected to run reliably for around eight days, and then hit a hidden duration-based barrier and slow to a crawl. In a wonderful demonstration of both the 4th-dimensional scaling problem and the S.E.P. principle at work, rather than try to figure out what was wrong and actually solve the problem, the programmers responsible simply wrote a script to deliberately checkpoint, crash, and restart the code once a week. (Sort of like Trotsky's "perpetual revolution," eh?)

But as Hilary is no doubt asking by now, what does all this have to do with writing? Well, all will become clear when we Meet the Fabians!

1 Someone Else's Problem. As the late Douglas Adams pointed out, the S.E.P. effect is incredibly powerful. You can make entire mountains disappear simply by declaring them S.E.P.