Habitability is not clarity. The danger of clarity is that it is uncompromised beauty — and it’s real tough to improve uncompromised beauty. One of the primary reasons abstraction is over-loved is that a complete program full of the right abstractions is perfectly beautiful. But if that set of abstractions does nearly the right thing, it is tempting to bend the entire surrounding structure to fit them. This leads to uninhabitable programs.
Simple Picture
ELI5: imagine a house so architecturally perfect that you cannot hang a picture without ruining the design. You live in it carefully, afraid to disturb anything. Compare that to a house that is slightly rough, slightly asymmetrical — but every corner fits your life, and you can change anything without guilt. The second house is habitable. The first is a museum you sleep in.
Habitability as the Primary Virtue
Habitability makes a place livable, like home. A habitable program can be comfortably understood so it can be comfortably changed. The primary feature for easy maintenance is locality — the ability to understand the source by looking at only a small piece.
Compression (meaning inferred from context) is the opposite of locality. Compressed code is sparser, but the more context a programmer needs, the more understanding required, and the more mistakes from misunderstandings. Overuse of abstraction and inappropriate compression contribute to uninhabitable programs.
This is locally-optimal applied to architecture: the perfectly abstracted system is a local optimum of elegance that resists improvement. Pirsig’s Quality was “a system at peace with itself” — Gabriel names the same: Quality is a subtle kind of freedom from internal contradictions. A system has this quality when it is at peace with itself.
To get wholeness you must leave rough and unimportant the things that don’t matter and give deep attention to the things that do. This is the via negativa of building: true wealth is subtractive, and true quality comes from knowing what not to polish.
Master Plans Freeze the Future
The existence of master plans alienates users: by definition, the community can have little impact because the most important decisions have already been made. Under a master plan, people are living a frozen future — able to affect only trivial details.
Neither users nor decision makers can visualize the actual implications of the plan. Bugs are not always errors — they reveal that we are not capable of producing a master plan. They tell us something about the territory the map could not capture.
When people lose a sense of responsibility for the environment they live in, and realize they are merely cogs in someone else’s machine — how can they feel identification or purpose? This is power congealing: the master plan concentrates design authority while distributing the consequences. The systems-bible confirms: systems develop goals of their own the instant they come into being, and great advances do not come from systems designed to produce great advances.
Lump-sum development creates a large artifact and allows it to deteriorate, minimally addressing problems until it is feasible to abandon and replace. Piecemeal development — building in small increments, each adapted to what was learned — is how organic order emerges. This is exploration applied to construction: the plan is valuable but the resulting plan is useless.
The Egoic System
When a system is too egoic it can feel lifeless and unreal. It is so filled with the will of the maker that there is no room for its own nature.
This is Tift’s insight about neurosis applied to software: the childhood strategy that was necessary becomes the adult prison. The architect who controls every detail prevents the system from developing its own life — just as the parent who controls every outcome prevents the child from developing their own will.
Organic order is the perfect balance between the needs of the parts and the needs of the whole. It cannot be designed from the top down — only cultivated through the ongoing negotiation between what the system needs and what its inhabitants need. This is Pirsig’s Static and Dynamic Quality in architectural form: Static Quality preserves the existing structure, Dynamic Quality allows it to evolve. Too much of either kills the system.
Creativity from Constraint
Creativity is spawned by constraint, similar to poetry. The automatic phrase is eliminated. Johnstone observed the same: saying “yes” to constraints produces spontaneity, while unlimited freedom produces paralysis. We never teach people to make up their own words, yet we teach budding programmers to create their own vocabulary.
The quality of the result depends on the quality of communication between builders — and this depends on whether it is fun to work on the project and whether it is personally important, not just monetarily. This is the “enough people” problem applied to building: the mission and the social satisfaction must be solved together, or neither works.
Common Misread
The dimwit take is “don’t plan — just hack.”
The midwit take is “good architecture means perfect abstractions — design it right the first time.”
The better take is that the goal is not perfect design but habitable design — code that can be understood locally, changed comfortably, and lived in over time. Perfect beauty is the enemy of habitable goodness. Systems are carpets with multiplicities of centers, not hierarchies with single tops. When you ask writers why they write, they say: to find out what happens in the end.
Main Payoff
For many years we were puzzle solvers, focused on turning algorithms into instructions. We enjoyed the complexity and viewed obscurity as evidence of skill. Aware now of our human limitations, we have come to view complexity and obscurity as faults, not challenges.
Patterns are merely ways to remember what we have forgotten — so we don’t forget the stuff we need to give our systems life, to give them the quality without a name. That quality: a system that is at peace with itself, where the free functioning depends not on meeting requirements but on the system coming to terms with itself and being in balance with the forces generated within it.
References:
- Richard P. Gabriel, Patterns of Software: Tales from the Software Community
- Christopher Alexander, The Timeless Way of Building (referenced throughout)