Christopher Alexander spent fifty years chasing something he could never name. He called it “the quality without a name” — a property that some buildings have and others don’t. You feel it when you walk into a room that works. You can’t point to why. The proportions, the light, the way the space breathes. It is alive. Most rooms are not.
He spent thirty years after A Pattern Language trying to pin it down. The Nature of Order — four volumes, 2,400 pages — identifies fifteen properties that living structures share: levels of scale, strong centers, boundaries, contrast, roughness, the void. Not rules. Properties. A Turkish carpet has them. A gothic cathedral has them. A well-worn wooden spoon has them.
Software documentation has none of them.
Open any component library’s docs. Storybook, Zeroheight, Docusaurus, whatever ships with your design system. The pages are flat. Every component gets the same template. The same prop table. The same “usage” section that nobody reads. There is no hierarchy of attention. No strong centers. No contrast between what matters and what is reference. The documentation is technically complete and experientially dead.
Alexander would say it lacks life. And he would be specific about why.
Levels of scale. Living structures have detail at every magnification. A cathedral has form at the city scale, the facade scale, the window scale, the stone-carving scale. Component docs have exactly one scale: the prop table. There is no zoom. No way to see the component in the context of a page, then in the context of a pattern, then in the detail of a single variant. It is flat. One level. Dead.
Strong centers. A living room has a hearth. A page should have a focal point — the one thing this component does that nothing else does. Most docs bury this in a description paragraph that reads like a commit message. “Button renders a clickable element.” That is not a center. That is a definition. A center would be: “Button is the moment where the user commits to an action. Everything else on the page is preamble.”
Roughness. Alexander’s most counterintuitive property. Living things are not perfectly regular. The handmade tile floor is more alive than the machine-cut one because the irregularities create information. Perfectly generated docs — where every component page is structurally identical — have no roughness. No component is more important than another. No page demands more attention. The uniformity is efficient and lifeless.
The void. Living structures have emptiness that is not absence but presence. The courtyard. The pause in music. The white space that says: this area is intentionally left open because not everything needs to be filled. Component docs fill every section because the template has sections. There is no void. No deliberate emptiness that says: this component is simple. It does one thing. There is nothing else to say.
Veneer generates documentation from intelligence. It reads what rafters knows — semantic meaning, consequences, conflicts, cognitive load — and renders it as browsable pages. But rendering intelligence is not the same as creating something alive. A page that shows all the data is not a page that lives.
The question veneer should be asking is not “what information goes on the component page?” The question is: does this page have a center? Does it have levels of scale? Does it earn its roughness? Does it know where to be empty?
Alexander never solved his problem. He spent fifty years reaching for a quality he could describe but not define, and he died in 2022 still reaching. But he left behind fifteen properties — not of architecture, not of software, not of documentation. Of life. Of the thing that makes a space worth being in.
A documentation site is a space. People spend time in it. They orient themselves. They find what they need or they don’t. They feel competent or they feel lost. That experience has a quality. Most documentation has no quality at all. It is complete and dead.
Veneer should build something alive.