Bringing Design
to Software
© Addison-Wesley, 1996
Profile 1. Software Design and Architecture
Profile Authors: Terry Winograd and Philip Tabor
Mitchell Kapor's Software Design Manifesto (Chapter 1) draws an analogy between software design and architecture. Kapor characterizes software design in terms of the theories of the Roman architect and architectural theorist Vitruvius, who proclaimed that well-designed buildings were those exhibiting the virtues of firmness, commodity, and delight.
Since the manifesto was originally presented, the architecture–software analogy has been repeated many times in the literature on human–computer interaction and software design. We in the software profession may have much to learn from the ancient and rich tradition of architectural practice and architectural theory. At the same time, in drawing such a broad analogy, it is possible to fall into superficiality, finding attractive but misleading guidance. This profile identifies some of the issues that the architectural analogy highlights about software design, relating them to the content of the subsequent chapters.
Roles in Design and Construction
In trying to understand the boundaries that distinguish software design, software engineering, interaction design, and the many other professional categories in our field, we can draw an analogy to the different roles in creating a building. In the simplest projects, designer, builder, and artisan are one. A single person or a small cooperative group sets out to build a structure. In contrast, developing a large software system, like constructing a building, is typically a large undertaking by many people. It calls for a division of labor, ranging from the broad vision of the whole project to the many small components, crafted by individuals or smaller groups. Yet the whole is seen by the user as a unity, rather than as a collection of more or less autonomous elements.
In modern building practice, we see a general division of labor among the architect, the builder (or contractor), and the individual laborers. The architect starts from the look-and-feel end of the problem—Vitruvius' commodity and delight. The engineers and builders are more concerned with the firmness of construction: with issues of economy, safety, and constructability.
As software design continues to mature, perhaps we will see a similar evolution: from the individual artisan-programmer (far from an extinct species today); to a master architect–builder, as described by Frederick Brooks (1995); to a commercial environment that includes software architectural firms that vie for awards for originality and elegance of their designs, but that are not responsible for construction (implementation). Kapor's call for a software-design profession that is distinct from programming suggests this separation of function between design and construction, and Gillian Crampton Smith and Philip Tabor (Chapter 3), describe the role of the artist-designer whose professional grounding is in the artistic, rather than engineering, disciplines.
Is this division of labor appropriate for software, or are design and construction more intimately related? Does a software system require, as Brooks suggests, an overarching master designer who brings a coherent and consistent vision to the vast teams that build the cathedrals and fortresses of the software world? Should programmers have kinds of legal and licensing requirements that civil engineers do, to assure the public of the firmness of the systems that affect lives (see Neumann, 1995, for a portrayal of computer risks)?
Of course, in the world of buildings, roles are not so neatly divided. The model of architect as distinct from builder is not prevalent in most of the world, and is not even that pervasive in the United States. Most everyday buildings are designed without the involvement of an architectural firm, by people whose training is in engineering, rather than in architecture. Do-it-yourselfers and small contractors make additions and changes to houses without the benefit of any formal architectural or engineering training—the equivalent of end users or local developers (see Nardi, 1993) modifying the computer-application code. What properties of our software will make it remodeler friendly, while preserving its firmness?
Design Education
The tradition of teaching in architecture differs from that of teaching in computing. It is grounded in the study of concrete examples and in direct engagement by students in a series of design projects. Budding architects are familiar with the great genres of the past: the Greek temple, the Gothic cathedral, the modern and postmodern skyscraper (Figure 1.1). They are presented with current precedent —previous designs, usually fairly recent, whose analysis and appraisal provide the raw material for theory and future practice. These designs may be classics, but they are not necessarily so: Students—and all practitioners—often learn more from disasters.
Figure 1.1 Genres in Architecture The Gothic cathedral is an example of an architectural genre—a social tradition of building that combines form and function in a coherent way across a wide variety of individual buildings. (Source: Courtesy of ????)
Kapor proposes a curriculum with courses such as the History of the Word Processor, just as an architecture student might study the history of the town square. Students would examine the different periods and genres (Figure 1.2), analyzing the development of the timeless concepts and seeing how those concepts have led to implementations in different architectural media (platforms and operating systems). Perhaps it is too early to base a software-design education on classics and precedents, as Kapor suggests; the field is so young, and is changing so rapidly. Or perhaps not, since the design-cycle times are so much shorter than are those of buildings. Students can begin by studying the design languages discussed by John Rheinfrank and Shelley Evenson (Chapter 4) and the emerging genres that carry social meaning, as described by John Seely Brown and Paul Duguid (Chapter 7).
Figure 1.2 Genres in Software The graphic-interface word processor represents a software genre, with established conventions and styles that cut across the individual products. Elements such as toolbars, rulers, and pulldown menus for styles are as conventional in this genre as are the characteristic arched windows and buttresses of the cathedral. (Source: Microsoft Word for Macintosh 5.0.)
The second component of architectural education is the studio. Students tackle design projects in an environment where experienced professionals review and critique their work. The spirit of teaching is not "Let me tell you all you need to know about how to design," but rather "Let me help you to understand and improve what you've done." Donald Schön (Chapter 9) has studied this kind of teaching extensively, and describes it as reflection in action. Although studio-based teaching is not a part of traditional engineering and computer-science education, it is a component of newer proposals for human–computer interaction curricula, such as the National Science Foundation study on New Directions in Human–Computer Interaction and Research (Strong, 1995) and the interdisciplinary student design projects sponsored by Apple, as described in Profile 9.
Architectural education also includes a more traditional body of instruction on the practical issues of building: structures, economics, materials, and the many details of construction. This component is analogous to the current education in software engineering, as distinct from computer science, which focuses on the technical engineering aspects and their theoretical foundations, often to the exclusion of practical concerns of management, economics, and the design process. As Donald Norman demonstrates in his tale of the Macintosh power switch (Chapter 12), all these dimensions can be relevant to the designer in surprising ways.
Style and Function
Architecture, like fashion, is a public art form. We are constantly exposed to new styles, each of which is a response to what came before. In architecture, a shared style develops over a long time; people know what a church or a house looks like, and each new instance develops a little from its predecessors. Software design, like architecture, is a cultural phenomenon, and therefore is subject to the forces of taste, fashion, and desire. Software is still much younger and less well developed, but we can see the development of styles—the 3270-display mainframe style, the Microsoft style, the Nintendo style—on which a designer can build.
Theoretical Framework
Just as Vitruvius' virtues of firmness, commodity, and delight can be mapped onto the software world, it is interesting to examine other conceptual structures that have been applied to architecture as well. For example, a work of architecture can be seen in terms of three interlocking domains: of material components, spaces, and experiences. So an architect might conceive of a building primarily as (1) an assembly of walls, floorplates and columns; (2) a cluster of spatial volumes, some squat, some lofty; or (3) a sequence of feelings induced in the user—of welcome, awe, constriction and release. Renaissance architectural theory tended to focus on the material components of architecture. Twentieth-century Modernism, with its emphasis on abstraction, immateriality, and expression, has stressed architecture's spatial and experiential components (widely influential texts were Giedion (1941) and Rasmussen (1959)).
Obvious parallels can be drawn to software, which traditionally has been designed with a focus on the computing itself: algorithmic form, function, and implementation. The software-design field is now turning to understand the nature of the human–computer interactions—the metaphorical spaces that people inhabit—and to the experience that software offers the user. Peter Denning and Pamela Dargan (Chapter 6) argue for a shift away from software design that is focused on the computer to software design that begins with the domain of action for the users. Crampton Smith and Tabor emphasize the ways in which interfaces communicate and shape the user's experience, rather than seeing interfaces as representations of underlying function.
Also, in considering the experience of the user as a basis for design, an issue of frequent concern to architects is that their client—the customer whom they have to satisfy with the design—often is not the end user. We are all familiar with buildings that are impressive monuments to the companies that commissioned them, but are inhabitant unfriendly. As Sarah Kuhn points out (Chapter 14), the same phenomenon is frequent in software systems: They are designed to meet needs of the client who commissions them, without being suitably designed in consideration of the end-user experience.
Beyond the Analogy
Having laid out the many areas of similarity, we could equally well point out substantial differences that distinguish software design from architecture—every comparison could be the starting point for a debate. The point, however, is not whether we can find a fit for every aspect of architecture in our understanding of software design. As with all metaphors and analogies, the value of looking at software design as architecture lies not in finding precise answers, but in raising provocative questions.
Suggested Readings
Christopher Alexander.Notes on the Synthesis of Form . Cambridge, MA: Harvard University Press, 1964.
Sigfried Giedion. Space, Time, and Architecture: The Growth of a New Tradition,. Cambridge, MA: Harvard University Press, 1941.
William J. Mitchell. City of Bits. Cambridge, MA: MIT Press, 1995.
Peter Neumann. Computer-Related Risks. Reading, MA: Addison-Wesley, 1995.
Steen Eiler Rasmussen. Experiencing Architecture (Second United States edition). Cambridge MA: MIT Press, 1959.