Joshua B. Gross
Why is it that architecture is such an appealing metaphor? Some metaphors are obvious, but architecture seems a surprising extension. What makes a software architect (or hardware architect) like a building architect? Why have we been captivated by Alexander?
Perhaps the most stunning difference between a software architect and a building architect is that the work by the software architect will never be seen by many people. Only a select group of developers will have the knowledge, access, or interest to observe a system’s architecture.
And yet other aspects of the metaphor apply: users can be said to inhabit a piece of software (e.g. ‘Unix is a nice place to live, but I wouldn’t want to visit’). Perhaps by inhabiting software, we begin to see its underlying logic, and through that lens, we glimpse (sorry, Plato’s cave wall is making a reappearance) the vision that the architect had.
This vision will inevitably be fleeting, because most software will be re-architected after a period of time. Fred Brooks was correct in diagnosing invisibility (Brooks, 1987) as a major cause of problems in software, but he didn’t get to the heart of the problem; invisibility leads to malleability. We believe that software can be changed and improved, and this alleviates some responsibility.
And so we get to the appeal of architecture (specifically) and art (in general) as metaphors for aspects of software development. Buildings are neither designed nor constructed casually, despite the fact that they are not necessarily more expensive than a software project (although certainly significantly less risky). The level of effort we place into “software architecture” may be extensive, but it still differs in respect to time.
Perhaps this metaphor should be removed from use. Perhaps we’re just fooling ourselves. However, the funny thing about identity is that it represents what we strive for, as well as what we are today.
The appeal of Alexander’s work can lie neither in its importance in architecture (we aren’t really valid judges of that) nor in his use of language (who can imagine quotidian developers reveling in TQWAN?). However, some of the appeal may be due the belief that what Alexander did was distill qualities that were designs for permanence.
It begins with Alexander’s language. the title The Timeless Way of Building (Alexander, 1979) not only emphasizes the work’s supposed freedom from the ravages of style and culture, but also its singular, definite nature; not a but the way.
In software, we crave this definitive, permanent guidance. We insist upon the unchanging nature of an industry not yet 75 years old: we cling to Moore’s law, and we insist, along with Brooks, that there are certain immutable, irreparable problems. We’ve latched on to patterns and pattern languages in attempt to achieve permanence.
However, art is not about the avoidance of risk; that is the fundamental flaw in this plan. If we are to create anything permanent, it is only because we have been willing to build many impermanent things. Timeless things are not built to be timeless, and there is no planning for permanence; they become timeless by surviving.
The same is true with architecture. Buildings are built to last, but their survival is not guaranteed. Instead, they need constant attention. To remain livable, they need constant maintenance and improvements.
So what are we missing? Art is the product of commitment, devotion, and love. Art controls its creator as much as it is controlled. We can create software designed for permanence, but not by controlling all aspects. We need to emphasize the emergent quality of our work. We need to let go of engineering as a discipline. If we believe that art holds the key (any key) to our maturation and progress, then we can’t have it both ways. We can’t have art without risk.
References
Alexander, C. (1979). The timeless way of building. Oxford, UK: Oxford University Press.Brooks, F. P., Jr. (1987). No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4), 10-19.