We join spokes together in a wheel, but it is the hole in the middle on which use of the wheel depends. Clay is fashioned into pots, but it is their empty hollowness that their use depends. The doors and windows are cut out to form a room, but it is the empty space within, that it's use depends. Therefore, while we work with the named things, Actions occur in the void.
Let’s run with the “Room” metaphor a bit.
We have lots of ways to describe walls. We have many different ways to take measurements, we can draw plans, we can describe different materials the wall could be made out of, we can talk about paint colors, trim pieces, straightness, decor, wiring, plumbing, even temperature. It makes sense that we can describe walls in detail, because, after all, they need to be built and we’ve been building them a long time. We work with the named things.
Things get a lot more difficult to describe (and a lot less specific) when someone starts talking about the area within those walls. In fact, we usually default to talking about dimensions first – which is a bit ironic, considering that the dimensions of a room is not really about the room at all, but more about how big the walls are.
Another interesting tidbit is this: Without a useful room, walls are worthless. You could build the highest quality wall ever, and if it doesn’t help create a useful void, nobody will care. There aren’t many wall-quality aficionados out there.
This is why building architects are treated like artists. Sure, they are doing engineering, but they are also designing something that will make lives better in an almost unknowable way. Art is merely building constructs to create useful voids; most art forms those voids are in the consumer’s consciousness; architecture creates voids in consciousness and physical spaces for actions (and other art) to take place.
I find it really confusing that software development is treated heavily as an engineering trade and not an art. Software development builds voids also, voids for actions to take place; the voids where the things happen.
Remember Chapter 3, where we learned to separate the things that know from the things that do when designing systems? The walls carry information, they know what color they are, and where they are, and what load limits they have- but they don’t do much. The room is where the actions happen, and there’s no information there. If you try to put information there, you’ll be putting things in the way of the action. The room then becomes smaller, cluttered, and less useful.
Bugs come from the room being messy, putting things there that shouldn’t be, and not cleaning up after yourself. Walking through a messy house you lose things (bad garbage collection), trip over things, and sometimes find something you didn’t expect. Traditional defect-rate-driven “code quality” comes from good architecture and interior design, not from building high quality walls.
You can write syntactically beautiful and standards-compliant code, that’s well documented and formatted for excellent readability – and it can still be buggy as hell. On the other hand, you can write code that no one else has a prayer of understanding, and have it be bulletproof. The difference is the architecture, the separation of actions and information.
We need to separate the problems of defect rate and readability, they are two separate problems that all too often are expected to have the same solution.
As an industry we tend to focus on improving coding standards and test coverage instead of learning the art of architecting (and refactoring) such that what we build is useful. We’re building better walls and smaller, more cluttered rooms, and we tell ourselves it’s okay because we’re using the best building materials we can find.
You, as the engineer, need to look beyond the materials and the nameable details, and instead see the voids the solution creates, and protect them so they can be useful. Actions occur in the void, and actions are why we write code.