I’m not going to talk about code for a while yet. Let’s talk about systems.
Scenario:
We have some complex system, we want to understand how things move in it. We iterate towards better, models—which are also more complex as they go on. Well, maybe they’re not better, but the way we interact with the models is definitely more complex.
There are reasons for this I have ideas about, but I won’t mention them here. [There’s a complexity limit on what can be exchanged with language, and so we have to stack metaphors that pass under the limit. While the model gets more capable and fine-grained, providing a better bridge between the metal and the human understanding, it also gets more baroque and hard to learn.]
In developing an understanding of the system, we start with a naive understanding, like this:
The system is flat. Everything is consistent. If you kick a rock, it moves. If you kick it again, or an identical rock in an identical way, it moves the same way. The rocks don’t interact with one another.
In this view, there are two things: the environment, and objects in it. It has certain characteristics:
- The objects don’t relate to one another
- The environment is the same everywhere
- Nothing moves on its own
The problem is that this is definitely not a good model. While it’s really simple and easy to communicate, the world plainly doesn’t work like this. Here’s a simple example: If I push a book of a table, it moves on its own and falls to the floor.
What we’ve got, for the physical world, is gravity. This is something invisible that affects the objects, and we need to develop an understanding of this thing, and then test our model of it against how this thing appears to work. Remember, we can’t see it directly!
It’s the inadequacies of our model of the thing-which-is-invisible that will drive our 3 steps of hunting for a better one.
Okay, so gravity is the thing-which-is-invisible in the physical world. What is it with software? I have no idea.
I don’t know what the thing-which-is-invisible is. It’s a combination of the way we understand code, social interactions, imageability, technology, the rest (I’m talking about code and coders here, not users. I’m talking about the actual characters and compilers and IDEs). It’s a mix. Maybe we’ll find out what the fundamental force is, one day, and give it a name. Here i’m dowsing for its existence by looking at general systems, and see how they behave, and then mapping their history onto the trajectory of code, and deducing that there’s this invisible thing there, this black hole. Systems forensics, we’ll call it.
Matt Webb, posted 2005-09-02 (talk on 2005-06-11)