Emergence

Perhaps the strongest evidence of an absence of independent thinking is susceptibility to intellectual fads. These things come and go almost as fast as pop music goes through its styles. In most cases the underlying concepts are sound but they are given broader applicability and greater credibility than they deserve. One such fad in the 1950s was information theory. Based on the brilliant work of Claude Shannon, information theory provided many new insights into a variety of fields. Unfortunately, plenty of people got carried away and tried to turn the entire world into one big Inforamation Theory spectacle. Another exemplar was chaos theory. The underlying mathematics of chaos theory is solid and it opened up some important new realms for mathematicians. But everybody jumped onto the chaos theory bandwagon, and pretty soon we were treated to Jurassic Park’s thesis that chaos theory proves that dinosaurs can’t be bred.

One current fad (unlike colds, there are always a number of intellectual fads going around at any given time) is "emergence". In its strictest and most academic form, the idea has some merit but there is a fundamental flaw in the popular interpretation of the concept. That popular interpretation might well be summarized as

"Emergence is a property of a complex system that permits the appearance of behavior unanticipated by the designer of the system."

My objection to this concept lies in the single word "unanticipated". If a system exhibits behaviors unanticipated by the designer, then I would call the system buggy, not emergent. If my car were to exhibit emergent behavior, such as steering left when I try to go right, I would take it to the repair shop.


OK, so let’s modify the popular definition:

"Emergence is a property of a complex system that permits the appearance of desirable behavior unanticipated by the designer of the system."

That’s better, but it creates a new problem: how can the designer know the difference between desirable and undesirable behavior if he can’t anticipate it in the first place? If this wonderful new behavior is something that the designer never anticipated, how can we be sure that it’s wonderful and not catastrophic? When, say, Microsoft Windows screws up, how many times does it crash and how many times does it produce a wonderful result, like, writing your doctoral thesis for you? There are a bajillion ways to get something wrong, and damn few ways to get it right. Bill Gates might be very pleased if Windows did in fact accidentally write your doctoral thesis for you, but he must also take the blame for the bazillion crashes that have lost millions of hours of work. Is that any way to design software?

Here’s my own definition:

"Emergence is a property of a complex system that strikes when the designer of the system writes code that operates at a higher level of abstraction than the designer understands."

Admit it — doesn’t this seem like a more intellectually honest definition of emergence? The key idea here is the notion of abstraction. The minute we step outside the bounds of single examples and start talking about rules based on abstractions, we run the risk of screwing up because our rules were applied to situations that we didn’t anticipate.

Here’s an example. Back around 1990 there was an arcade racing game that featured billboards for beer brands along the racetrack. It turns out that the designers were just trying to improve the immersive qualities of their game, but everybody else smelled the evil hand of beer companies paying videogame makers to advertise their products to vulnerable American youth. So some earnest and well-meaning politician introduced a bill to the California State Legislature that would ban any games sold to minors that depicted alcoholic beverages. I ended up testifying before the committee that was considering the bill. I showed them my game Balance of the Planet, a noble educational simulation of environmental issues. And right there in the middle of it was an image of a garbage dump with an unmistakable image of a discarded vodka bottle. My sweet and noble educational simulation would be banned by this legislation! Oops! It died in committee.

That’s the problem with abstraction: it covers so many cases, it’s hard to anticipate all of them. Which of course is always the source of software bugs. “I never thought that situation would occur” is the plea of so many programmers caught red-handed with a bug.

Listen, people, this is important: mastering abstraction is the very heart and soul of good software design. The top designers think in abstract terms, not in individual cases. They can see things – anticipate things – that mere mortals don’t see. That’s what makes them great designers.

Thinking abstractly often means thinking in mathematical or statistical terms. For example, I do not test a storyworld in the Erasmatron by simply playing through it; that’s absurdly narrow. Instead, I run a routine (called a rehearsal, appropriately enough) that runs through the storyworld hundreds of times with slightly different conditions, building up a statistical image of the results. I then examine that statistical image to evaluate the storyworld. You see tables of numbers, but I see drama at an abstract level: how often actors resort to violence, the amount of overall conflict or boredom; how many interactions arise in different pairings of actors. All these numbers, taken together, give me a clearer image of the overall storyworld than simply playing it would do. It’s a different way of thinking about drama, utterly alien to those who think in terms of conventional storytelling. But this is the stuff and substance of real software design.

So start getting abstract, and may nothing ever emerge from your software.

Emergent Software