On Subsystems and Selves
Wednesday, June 2, 2010 at 6:35PM 
Simple diagram of The Application of Object-Oriented Design Techniques to the Evolution of the Architecture of a Large Legacy Software SystemIn a later post I'll tell you about the subsystems in the game Puzzle Strike, but first I thought we could discuss subsystems in general. Disclaimer: this post is intentionally labyrinthine because that's how thinking about things works.
Christopher Alexander
Christopher Alexander wrote the book on subsystems back in 1964 and it's still very much worth reading. He explained that sometimes a system is made up of a web of deeply interconnected relationships, or in other words: a mess. If changing any part of a system means you disrupt everything else, it's very hard to tinker with and improve without ruining something. On the other hand, it's easier to deal with a system when its made up of subsystems that (though they might themselves have interwoven webs of connections) do not have many connections among each other. This way, if you tinker with subsystem A, you probably won't ruin subsystem B by doing so.
Computer programmers are well aware of this concept. The Model-View-Controller architecture is one example in that it separates 1) the stuff the user interacts with, 2) the stuff the going on behind the scenes, and 3) the stuff the user sees. If you need to rewrite the stuff the user sees, this hopefully has little effect on the other two subsystems.
Another point Alexander brings up is that when we encounter some system, we naturally try to view it as a collection of subsytems, but the way we choose to carve things up can be based on our personal biases. In fact, it can even be determined by the language we speak. The set of all possible subsets of a system is usually so large that it far exceeds the number of words in our language. If our language happens to have a word that describes something, we're more likely to carve things up THAT way, just because we have a way of talking about it. Some languages have more words than ours does for snow, or more words for happiness, or more words for types of small rivers, etc.
As an example, imagine we were going to build a building. That's a very complicated system. What are the subsystems? Maybe plumbing, electrical, and load-bearing materials are three of the subsystems. After all, each of those things has a lot going on within the subsystem but relatively few connections between subsystems. But we could slice things up differently. Maybe some of the plumbing is made of copper pipes. Maybe some of the electrical has copper, and perhaps some other part of the building uses copper, too. Maybe copper parts are subsystem, all related in that they are susceptible to rust and water damage over time. Or what about simply "the bathroom" as a subsystem? Everything in a bathroom must work together, fit, be functional, not cost too much, be aesthetically pleasing, etc, even though it contains plumbing, electrical, and load-bearing materials.
Alexander's point with all that is actually that the best way to carve up a system tends to be the way that gives you the most disparate (as in not tightly woven) subsystems.
Many years ago, I was lucky enough to talk with Will Wright, and I read Notes on the Synthesis of Form on his recommendation. I saw on his whiteboard a diagram of the subsystems of The Sims Online. I couldn't help mentioning the idea that perhaps there was some other set of subsystems, and perhaps the ones written there were simply easier to SAY, as opposed to being the best ones. He said yes, good point, and looked at the diagram. Then he said, "actually, the instant messenger isn't really listed here, it's part of several of these subsystems but maybe it would be better to think of that as its own node."
Susan Blackmore
The ultimate in systems is the
