The most beautiful code in the company is the code nobody dares to change.
Suppose a team builds a program on abstractions so clean that every part follows from a few ideas. Then a requirement arrives that the abstractions almost, but not quite, cover. Nobody wants to spoil the design, so the surrounding code gets bent to fit the abstractions instead. A year later the program is still elegant, and nobody dares to touch it.
Richard Gabriel’s Patterns of Software argues that this is the normal fate of beautiful code, and that we have been aiming at the wrong virtue. Habitability is not clarity. The danger of clarity is that it is uncompromised beauty, and it’s real tough to improve uncompromised beauty.
Living in the code
Habitability is what makes a place livable, like home. A habitable program can be comfortably understood, so it can be comfortably changed, and the main thing that makes it understandable is locality: you can grasp a piece of the source by looking only at that piece.
Abstraction cuts against locality when it becomes compression, where meaning is inferred from context: the more context a programmer needs, the more mistakes come from misunderstanding. In the elegant program above, every small edit requires holding the whole design in your head. Overuse of abstraction and inappropriate compression contribute to uninhabitable programs.
So Gabriel’s standard is not perfection. Quality is a subtle kind of freedom from internal contradictions. A system has it when it is at peace with itself, close to what Pirsig meant by Quality in Zen and the Art of Motorcycle Maintenance, and that peace comes from proportion rather than polish: To get wholeness you must leave rough and unimportant the things that don’t matter and give deep attention to the things that do.
Why master plans fail
The elegant program is a small master plan, and Gabriel, following the architect Christopher Alexander, distrusts master plans. Under one, the most important decisions have already been made, and those who live in the result can only affect trivial details. Bugs are not always errors; they show that we are not capable of producing a master plan.
The alternative is piecemeal growth: building in small increments, each adapted to what the last one taught you, so that organic order emerges from the ongoing negotiation between the needs of the parts and the needs of the whole. This does not make planning worthless. Thinking through a design is valuable; treating the resulting plan as fixed is what freezes the future.
Underneath is a failure of temperament. 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. The team that refused to change its abstractions was protecting its own idea of the program, not the program’s ability to grow.
Puzzles and homes
Gabriel traces the problem to programmers’ self-image. For years we were puzzle solvers who enjoyed 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.
That shift changes what good design means: the goal is not perfect design but habitable design — code that can be understood locally, changed comfortably, and lived in over time. A habitable program, like a story, does not know its ending in advance. When you ask writers why they write, they say: to find out what happens in the end.
References:
- Richard P. Gabriel, Patterns of Software: Tales from the Software Community
- Christopher Alexander, The Timeless Way of Building (referenced throughout)