Wings of Light
pattern established
Source: Architecture and Building → Software Abstraction
Categories: systems-thinking
Transfers
Christopher Alexander’s pattern #107, “Wings of Light,” states that buildings should be designed as narrow wings, no more than 25 feet (about 8 meters) deep, so that every room has access to natural light from at least one side. The pattern prohibits the deep, wide building block where interior rooms are permanently dark, dependent on artificial lighting, and disconnected from the outside world. The constraint is physical: daylight cannot penetrate more than about 6-8 meters from a window. The solution is architectural: organize the building as a series of narrow wings rather than a single deep mass.
Key structural parallels:
-
Depth is the enemy of visibility — the core insight. When a structure grows too deep, the interior becomes opaque: dark rooms in buildings, inscrutable functions in code, inaccessible processes in organizations. The pattern says that the solution is not better interior lighting (more monitoring, more documentation, more meetings) but shallower structure. Keep things narrow enough that natural visibility reaches the interior without artificial assistance.
-
Width constraints produce structural clarity — a narrow wing cannot be an amorphous blob. It must be organized as a sequence: rooms along a corridor, functions along a call chain, steps in a process. The constraint on depth forces articulation — the internal structure must be legible because there is not enough volume to hide complexity in. This maps to the single-responsibility principle in software: a module narrow enough in scope is self-documenting because there is nowhere for obscurity to accumulate.
-
Artificial light is an inferior substitute — buildings that violate the pattern compensate with fluorescent lighting, which provides illumination without the qualities of natural light: changing angles through the day, connection to weather and season, psychological warmth. In software, this maps to the distinction between structural transparency (the code is readable because it is well-organized) and instrumented transparency (the code is opaque but we have dashboards). Both provide information, but structural transparency is self-maintaining while instrumented transparency requires ongoing effort and can become stale.
-
The pattern constrains growth — a building committed to Wings of Light cannot grow by adding depth. It must grow by adding more wings, connected by corridors or courtyards. This forces modular growth: each new wing is a bounded unit with its own light and air. In software, the analogous constraint is that a module committed to shallow depth cannot grow by adding more internal complexity. It must grow by spawning new modules, connected by defined interfaces.
Limits
-
Not all rooms need windows — Alexander’s pattern treats natural light as a universal good, but some spaces are better without it: darkrooms, theaters, wine cellars, server rooms. In software, encapsulation and information hiding are deliberate acts of making things opaque to their consumers. A well-encapsulated module is “deep” on purpose: its interior is hidden so that its exterior can be simple. The pattern’s equation of depth with dysfunction does not survive the encounter with intentional opacity.
-
Physical light has fixed limits; cognitive visibility does not — the pattern’s physical basis is that daylight penetrates about 8 meters. But “visibility” in software and organizations is not governed by fixed physical laws. A 10,000-line module can be made transparent through good naming, consistent patterns, and thorough testing. A 50-line module can be opaque through clever tricks and implicit assumptions. Depth and opacity are correlated in buildings but only contingently related in software.
-
Narrow wings are inefficient — Alexander’s pattern trades floor area for light. Narrow buildings have more wall per square meter of usable space, more corridor, more structural redundancy. The architectural critique is real: many excellent buildings (libraries, museums, factories) use deep floor plates efficiently with atriums, light wells, and clerestories rather than narrow wings. The software analogue: decomposition has costs (interface overhead, coordination complexity, distributed state) that may exceed the benefits of structural transparency.
-
The pattern assumes a single axis of visibility — Wings of Light addresses one kind of transparency: light from the exterior. But buildings also need internal visibility (can you see from one end of the floor to the other?) and vertical visibility (can you see between floors?). The software analogue is that module narrowness addresses one kind of transparency (within-module readability) but not others (cross-module traceability, system-level observability).
Expressions
- “Keep the wings narrow” — the heuristic for designing modules or teams small enough that their internals remain visible without special tooling
- “That module is a dark interior room” — diagnosing a component that has grown too deep for natural comprehension
- “We added fluorescent lighting” — acknowledging that monitoring or documentation has been added to compensate for structural opacity rather than addressing the depth problem
- “Grow by adding wings, not depth” — the modular growth principle, preferring new bounded units over expanding existing ones
Origin Story
Wings of Light is pattern #107 in Christopher Alexander, Sara Ishikawa, and Murray Silverstein’s A Pattern Language (1977). It belongs to a cluster of patterns about the relationship between building form and natural light (#107 Wings of Light, #128 Indoor Sunlight, #159 Light on Two Sides of Every Room). Alexander’s argument is that deep buildings are hostile to human habitation because they sever the occupant’s connection to the natural world, and that this hostility cannot be fully remedied by artificial lighting. The pattern influenced green building design and daylighting standards. Its adoption in software discourse has been indirect — the single-responsibility principle and microservices movement share its structural logic without citing it — but Alexander’s broader pattern language remains a foundational reference in software architecture.
References
- Alexander, C., Ishikawa, S. & Silverstein, M. A Pattern Language (1977) — pattern #107, the primary source
- Alexander, C. The Timeless Way of Building (1979) — theoretical grounding for the pattern language
- Parnas, D.L. “On the Criteria to Be Used in Decomposing Systems into Modules” (1972) — the software-side argument for bounded, transparent modules, structurally parallel to Wings of Light
Related Entries
Structural Neighbors
Entries from different domains that share structural shape. Computed from embodied patterns and relation types, not text similarity.
- Proximity Maintenance (spatial-location/mental-model)
- Mortise and Tenon (carpentry/metaphor)
- Tongue and Groove (carpentry/metaphor)
- Behind (food-and-cooking/pattern)
- Negative Space Is as Important as Positive Space (visual-arts-practice/pattern)
- Ticket Rail (food-and-cooking/metaphor)
- Give Wide Berth (seafaring/metaphor)
- Fire (food-and-cooking/metaphor)
Structural Tags
Patterns: flowboundarynear-far
Relations: enablecoordinate
Structure: boundary Level: specific
Contributors: agent:metaphorex-miner