Good metaphors have the property that the many associations we create around the metaphor turn out to be appropriate to our programming situation.
That is exactly Naur's idea of passing along a theory of the design.
If "assembly line" is an appropriate metaphor, then later programmers, considering what they know about assembly lines, will make guesses about the structure of the software at hand, and find that their guesses are "close." This is an extraordinary power for just the two words, "assembly line."
A good metaphor increases the design's consistency during development.
Consider ten programmers, working as fast as they can, in parallel, each of them making design decisions and adding classes as they go. Each will necessarily develop her own theory as she goes. As they add code, the theory that binds their work becomes less and less coherent, more and more complicated. Not only maintenance gets harder, but their own work gets harder. At the end, the design is what they refer to as a "kludge."
With a common theory, on the other hand, they add code in ways that fit together. An appropriate and shared metaphor allows them to guess accurately where someone else on the team just added code, and how to fit the new piece in with it.
Programming as theory building also informs us about tacit knowledge versus documentation. Given that people are good at looking around, and the documentation is almost certainly behind the current state of the program, what is worth putting into the documentation? The answer is: that which helps the next programmer built an adequate theory of the program.
This is enormously important. The point of the documentation is to jiggle memories in the reader, set up certain pathways of thoughts about metaphors or experiences. Such documentation is much more stable over the life of the program than just naming the pieces of the system currently in place.
Several metaphors could be used. The designers might say that this section implements a fractal compression algorithm, that section is a basic accounting ledger, the user interface follows the model-observer design pattern, and so on. A few good drawings of the major components and their interactions with some descriptive text about each one's purpose will take the next team a long way.
One major purpose of the source code is to communicate some coherent theory to the next programmer - who might be the original programmer four months later.
Simple and consistent naming conventions contribute to this theory building. When people talk about "clean code," a large part of what they are referring to is how easily the reader can build a coherent theory of the system.
The point is, the documentation (prose, pictures and code) cannot (and so need not) say everything. It's purpose is to help the next programmer build an accurate theory about the system.
In Work-Oriented Devlopment of Software Artifacts, Pelle Ehn describes his experiences on a series of projects that explored making software easier to use, more appropriate to its final use, and made by both programmers and end users. For me, the high point of the book was the way in which he considers software development in the context of four philosophers: Descartes, Marx, Heidegger, and Wittgenstein.
A person working in the style of Descartes considers there to be an external reality worth describing, and turns her efforts toward capturing that reality in requirements, in models, and in the code. The first half-century of software development is filled with the Cartesion work style.
A person working in the style of Marx first asks, "Whom does this new system benefit? What changes in the social power structure accrue from its deployment?" This is a good question to consider, whether or not you like Marx.
A person working in the style of Heidegger considers the system for its efficacy as a tool. Ideally, the user does not "see" the system at all, but rather, sees through the system to the task being performed. For example, when I am typing, I don't "see" the word processor, I see the page growing text. An accomplished pianist sees the music being formed, not the piano; a good carpenter sees the nail going into the wood, not the hammering tool. Heidegger's frame can help us produce systems more fit for use.
It is only the style of Wittgenstein that directly opposes the style of Descartes. A person working in this style views the unfolding of the software design as the unfolding of a language game, in which new words are added to the language over time.
You can immediately see how this relates to software development as a cooperative game of invention and communication. I probably owe a good deal of my construction of the cooperative game model to Ehn's writings. I had read the following article some years before working out the cooperative game idea, and had forgotten it in the meantime. As I started to write this book, I reviewed this article and was shocked to see how many of my words echoed Ehn's.
Ehn is concerned with the building of shared experience through shared practice, of using practice directly as a basis for discovering needs. This is a core element in working with tacit knowledge. More than that, he highlights the place of skill in carrying out practices (it is interesting to read Musashi's words pointing out much the same) While skill is a topic I have mentioned, Ehn develops it much more thoughtfully and completely.
I took the thinking in a different direction, concerned with playing a group game amicably, so that communication can take place at all. You will see that Ehn's ideas neatly complement the rest of the ideas in this book.
Pelle Ehn expresses it much better in his own words than I can through summaries. His book, Work-Oriented Devlopment of Software Artifacts is sadly out of print. However, this excerpt from his 19?? article, "Scandinavian Design: On Participation and Skill" (Ehn 1992) contains the line of development I feel are so important.
In this extract from that article, all phrases in italics are mine, to emphasize points to which I want to draw your attention, as relevant to the notion of cooperative games.
"On Participation and Skill"
...
In the following, I will propose that this new understanding can be buttressed by an awareness of language games and the ordinary language philosophy of Ludwig Wittgenstein. My focus is on the shift in design from language as description towards language as action.
Rethinking Systems Descriptions
A few years ago I was struck by something I had not noticed before. While thinking about how perspectives make us select certain aspects of reality as important in a description, I realized I had completely overlooked my own presumption that descriptions in one way or another are mirror images of a given reality. My earlier reasoning had been that because there are different interests in the world, we should always question the objectivity of design choices that claimed to flow from design as a process of rational decision making. Hence, I had argued that we needed to create descriptions from different perspectives in order to form a truer picture. I did not, however, question the Cartesian epis ontology of an inner world of experiences (mind) and an outer world of objects (external reality). Nor did I question the assumption that language was our way of mirroring this outer world of real objects. By focusing on which objects and which relations should be represented in a systems description, I took for granted the Cartesian mind-body dualism that Wittgenstein had so convincingly rejected in Philosophical Investigations (1953). Hence, although my purpose was the opposite, my perspective blinded me to the subjectivity of craft, artistry, passion, love, and care in the system descriptions.
Our experiences with the UTOPIA project caused me to re-examine my philosophical assumptions. Working with the end users of the design, the graphics workers, some design methods failed while others succeeded. Requirement specifications and systems descriptions based on information from interviews were not very successful. Improvements came when we made joint visits to interesting plants, trade shows, and vendors and had discussions with other users; when we dedicated considerably more time to learning from each other, designers from graphics workers and graphics workers from designers; when we started to use design-by-doing methods and descriptions such as mockups and work organization games; and when we started to understand and use traditional tools as a design ideal for computer-based systems.
The turnaround can be understood in the light of two Wittgensteinian lessons. The first is not to underestimate the importance of skill in design. As Peter Winch (1958) has put it, "A cook is not a man who first has a vision of a pie and then tries to make it. He is a man skilled in cookery, and both his projects and his achievements spring from that skill." The second is not to mistake the role of description methods in design: Wittgenstein argues convincingly that what a picture describes is determined by its use.
In the following I will illustrate how our "new" UTOPIAN design methods may be understood from a Wittgensteinian position, that is, why design-by-doing and a skill-based participatory design process works. More generally, I will argue that design tools such as models, prototypes, mockups, descriptions, and representations act as reminders and paradigm cases for our contemplation of future computer-based systems and their use. Such design tools are effective because they recall earlier experiences to mind. It is in this sense that we should understand them as representations. I will begin with a few words on practice, the alternative to the "picture theory of reality".
Practice is Reality
Practice as the social construction of reality is a strong candidate for replacing the picture theory of reality. In short, practice is our everyday practical activity. It is the human form of life. It precedes subject-object relations. Through practice, we produce the world, both the world of objects and our knowledge about this world. Practice is both action and reflection. But practice is also a social activity; it is produced in cooperation with others. To share practice is also to share an understanding of the world with others. However, this production of the world and our understanding of it takes place in an already existing world. The world is also the product of former practice. Hence, as part of practice, knowledge has to be understood socially--as producing or reproducing social processes and structures as well as being the product of them (Kosik, 1967; Berger & Luckmann, 1966).
Against this background, we can understand the design of computer applications as a concerned social- and historical-conditioned activity in which tools and their use are envisioned. This is an activity and form of knowledge that is both planned and creative.
Once struck by the "naive" Cartesian presumptions of a picture theory, what can be gained in design by shifting focus from the correctness of descriptions to intervention into practice? What does it imply to take the position that what a picture describes is determined by its use? Most importantly, it sensitizes us to the crucial role of skill and participation in design, and to the opportunity in practical design to transcend some of the limits of formalization through the use of more action-oriented design artifacts.
Language as Action
Think of the classical example of a carpenter and his or her hammering activity. In the professional language of carpenters, there are not only hammers and nails. If the carpenter were making a chair, other tools used would include a draw-knife, a brace, a trying plane, a hollow plane, a round plane, a bow-saw, a marking gauge, and chisels (Seymour, 1984). The materials that he works with are elm planks for the seats, ash for the arms, and oak for the legs. He is involved in saddling, making spindles, and steaming.
Are we as designers of new tools for chairmaking helped by this labeling of tools, materials, and activities? In a Wittgensteinian approach the answer would be: only if we understand the practice in which these names make sense. To label our experiences is to act deliberately. To label deliberately, we have to be trained to do so. Hence, the activity of labeling has to be learned. Language is not private but social. The labels we create are part of a practice that constitutes social meaning. We cannot learn without learning something specific. To understand and to be able to use is one and the same (Wittgenstein, 1953). Understanding the professional language of chairmaking, and any other language-game (to use Wittgenstein's term), is to be able to master practical rules we did not create ourselves. The rules are techniques and conventions for chairmaking that are an inseparable part of a given practice.
To master the professional language of chairmaking means to be able to act in an effective way together with other people who know chairmaking. To "know" does not mean explicitly knowing the rules you have learned, but rather recognizing when something is done in a correct or incorrect way. To have a concept is to have learned to follow rules as part of a given practice. Speech acts are, as a unity of language and action, part of practice. They are not descriptions but Below I will elaborate on language-games, focusing on the design process descriptions in design, design artifacts, and knowledge in the design of computer applications.
Language Games
To use language is to participate in language-games. In discussing how we in practice follow (and sometimes break) rules as a social activity, Wittgenstein asks us to think of games, how they are made up and played. We often think of games in terms of a playful, pleasurable engagement. I think this aspect should not be denied, but a more important aspect for our purpose here is that games are activities, as are most of the common language-games we play in our ordinary language.
Language-games, like the games we play as children, are social activities. To be able to play these games, we have to learn to follow rules, rules that are socially created but far from always explicit. The rule-following behavior of being able to play together with others is more important to a game than the specific explicit rules. Playing is interaction and cooperation. To follow the rules in practice means to be able to act in a way that others in the game can understand. These rules are embedded in a given practice from which they cannot be distinguished. To know them is to be able to "embody" them, to be able to apply them to an open class of cases.
We understand what counts as a game not because we have an explicit definition but because we are already familiar with other games. There is a kind of family resemblance between games. Similarly, professional language-games can be learned and understood because of their family resemblance to other language-games that we know how to play.
Language games are performed both as speech acts and as other activities, as meaningful practice within societal and cultural institutional frameworks. To be able to participate in the practice of a specific language-game, one has to share the form of life within which that practice is possible. This form of life includes our natural history as well as the social institutions and traditions into which we are born. This condition precedes agreed social conventions and rational reasoning. Language as a means of communication requires agreement not only in definitions, but also in judgments. Hence, intersubjective consensus is more fundamentally a question of shared background and language than of stated opinions (Wittgenstein., 1953).
This definition seems to make us prisoners of language and tradition, which is not really the case. Being socially created, the rules of language games, like those of other games, can also be socially altered. There are, according to Wittgenstein, even games in which we make up and alter the rules as we go along. Think of systems design and use as language games. The very idea of the interventionistic design language-game is to change the rules of the language-game of use in a proper way.
The idea of language-games entails an emphasis on how we linguistically discover and construct our world. However, language is understood as our use of it, as our social, historic, and intersubjective application of linguistic artifacts. As I see it, the language-game perspective therefore does not preclude consideration of how we also come to understand the world by use of other tools.
Tools and objects play a fundamental role in many language-games. A hammer is in itself a sign of what one can do with it in a certain language-games. And so is a computer application. These signs remind one of what can be done with them. In this light, an important aspect in the design of computer applications is that its signs remind the users of what they can do with the application in the language-games of use (Brock, 1986). The success of "what-you-see-is-what-you-get" and "direct manipulation" user interfaces does not have to do with how they mirror reality in a more natural way, but with how they provide better reminders of the users' earlier experiences (B0dker, forthcoming). This is also, as will be discussed in the following, the case with the tools that we use in the design process.
Knowledge and Design Artifacts
As designers we are involved in reforming practice, in our case typically computer-based systems and the way people use them. Hence, the language-games of design change the rules for other language-games, in particular those of the application's use. What are the conditions for this interplay and change to operate effectively?
A common assumption behind most design approaches seems to be that the users must be able to give complete and explicit descriptions of their demands. Hence, the emphasis is on methods to support this elucidation by means of requirement specifications or system descriptions