System Metaphor in "Extreme Programming": A Semiotic Approach

System Metaphor in “Extreme Programming”:
A Semiotic Approach
Rilla Khaled1, Pippin Barr1, James Noble1 and Robert Biddle2
1 School of Mathematical and Computing Sciences
Victoria University of Wellington
Wellington, New Zealand
{rkhaled, chikken, kjx}@mcs.vuw.ac.nz
2 Human-Oriented Technology Laboratory
Carleton University
Ottawa, Canada
robert biddle@carleton.ca
Abstract. System Metaphor is one of the core practices of the software develop-
ment process known as “Extreme Programming” (XP). Unfortunately, the Sys-
tem Metaphor practice is poorly understood, and is the practice XP teams most
commonly choose to ignore. We provide a simple, structural model of system
metaphors, based upon Peircean semiotics, giving a fundamental account of the
way metaphors can contribute to a software system. Using this model, we iden-
tify activities that teams can use to develop metaphors for their systems, and tech-
niques for evaluating system metaphors. We hope this analysis will encourage XP
teams not to abandon system metaphors, but rather, to continue to use metaphors
to strengthen their development practices.
1 Introduction
Extreme Programming (XP) [1] is an new and acclaimed approach to software devel-
opment process. The goal of XP it to allow software developers to “embrace change”,
and successfully address the problem of vague and changing requirements. XP is one
of several “agile” processes, which distinguish themselves from more traditional ap-
proaches by their innovative lightweight techniques. XP involves using a number of
explicit “practices”, some of which address technical issues, such as code refactoring
and test-first development, and some of which address human issues, such the on-site
customer, and the “planning game”. One of the twelve core practices is the System
Metaphor.
The system metaphor is a means of communicating about the project in terms that
both developers and customers will understand, and which does not require pre-existing
familiarity with the problem domain [2]. The system metaphor guides the mental mod-
els that project members have of the system, and shapes a logical architecture for the
system. Experience with XP shows that the system metaphor practice is the most com-
monly dropped practice, due to a lack of understanding of how to use it, and the diffi-
culty of finding an appropriate metaphor [3, 2, 4]. Martin Fowler sums up a widely held
sentiment about metaphor [5–8] when he says the following in Chapter 1 of Extreme
Programming Examined:

---

. . . I still haven’t got the hang of this metaphor thing. I saw it work, and
work well, on the C3 project, but it doesn’t mean I have any idea how to do it,
let alone how to explain how to do it [9].
In this paper, we set out to address these issues using semiotics. Our primary aim is
to understand how system metaphor works, and our secondary aim is to suggest how
to identify useful system metaphors, and thereby assist people trying to do the practice.
To understand system metaphors, we have analysed their structure using semiotics. In
particular, we use techniques from Peirce, and Lakoff & Johnson to develop a formal
semiotic model of metaphor in extreme programming.
While the model itself is an advance for understanding and reasoning about metaphor,
to make system metaphor more accessible on a practical level, we present a set of ac-
tivities for finding potential system metaphors, and a set of criteria for evaluating them,
based on our semiotic analysis but capable of independent application. XP teams can
use these activities and criteria to support their development practices, thus profiting
from our analyses, without necessarily having to appreciate the semiotic model upon
which they are based.
Section 2 of this paper discusses the current state of the System Metaphor prac-
tice within the XP community, and existing suggestions for improvement. Section 3
contains a brief introduction to Peircean semiotics, a structural model of metaphor in
general, and the application of semiotics in Computer Science. In section 4 we present
our structural model of the XP system metaphor, detailing each component by applying
it to the Chrysler C3 payroll system metaphor, the best known example of a success-
ful XP system metaphor. Section 5 contains a list of process activities for establishing
metaphors suitable for use by XP developers as well as various metaphor evaluation
considerations. In section 6 we outline future directions for this work and finally in
section 7 we present our conclusions.
2 Extreme Programming and Metaphor
The System Metaphor practice is a way of explaining the logical architecture of a sys-
tem by describing it in terms of something with which developers and customers are al-
ready familiar [5, 2]. A system metaphor facilitates discussion of the project in language
that is accessible to both customers and developers, providing a shared vocabulary for
discussing system problems and solutions [8, 3]. For developers, a system metaphor
additionally supports consistency in naming elements of their programs, including sub-
systems, packages, classes, and methods [10].
The paradigmatic XP system metaphor is the PAYROLL SYSTEM IS AN ASSEMBLY
LINE metaphor used for the Chrysler C3 payroll system [11, 12]. This metaphor makes
extensive use of manufacturing concepts, such as lines, stations, bins, and parts. The
C3 metaphor works roughly in the following manner: a person’s paycheque is a com-
bination of parts, where parts initially relate to hours worked, e.g. basic gross pay. The
parts move down the assembly line and are placed into input bins, which then supply
these parts to stations. Each station works in sequence, and processes the parts, where
processing consists of debiting or crediting further amounts to the initial amount, e.g.

---

income tax, pension, overtime, union dues, and so forth. These processed parts are then
placed into output bins, and in turn get processed by other stations. The final paycheque
consists of an assemblage of all of the output parts resulting from each station in the
assembly line [12].
The metaphor plays a role in shaping the “logical architecture” of the system. In
Extreme Programming Explained, Beck gives explanations of how the metaphor shapes
the architecture [1]:
The metaphor just helps everyone on the project understand the basic ele-
ments and their relationships. Words chosen to identify technical entities should
be consistently taken from the chosen metaphor. As development proceeds and
the metaphor matures, the whole team will find new inspiration from examining
the metaphor.
Consistent with the XP mind set of avoiding investment in the unknown, the system
metaphor is a “cheap” system design, in that it suggests major system components and
their interactions. Additionally, good metaphors have generativity, thus allowing people
to broach new ideas and questions regarding the system they would not have otherwise
raised [13]. Said the C3 developers on the topic of their system metaphor [11]:
The team had the benefit of a very rich domain model developed by mem-
bers of the team in the project’s first iteration. It gave the members of the project
an edge in understanding an extremely complex domain.
Yet for all the benefits of metaphors, in practice they are difficult to come up with
and to use [3, 2, 4]. Unfortunately, there is little literature available on how to choose and
use a metaphor — research on the system metaphor practice is quite sparse, especially
when compared to the wealth of research considering other XP practices, such as Pair
Programming, Test-Driven Development, or the Planning Game.
It seems that the typical approach for finding a metaphor is by a process of trial and
error, to see if the suggested metaphor “fits”. Wake also suggests combining metaphors
if a single appropriate metaphor cannot be found, or alternatively using the “na¨ıve”
metaphor, where the system stands for itself. He also suggests dropping the use of the
metaphor if it stops working [3].
The system metaphor faces an even deeper problem however, which is the question
of whether it really is of any help, especially if the chosen metaphor later turns out to
be incorrect or unhelpful [9, 7, 8, 5]. Studies of projects using XP have shown not only
that chosen metaphors are usually poor, but also that these poor metaphors are very
underutilised during development [4, 14]; this is borne out in our own experience of
XP projects in an educational environment [15]. Typical concerns are that the chosen
metaphor is too weak, thus not providing any insight into potential architectural plans
or providing enough vocabulary, or conversely that the chosen metaphor is too strong,
thereby forcing system components into a form that they do not logically mould into.
Maybe the chosen metaphor is too unfamiliar to the team members to provide any value
(which may be the case if an earlier development team established the metaphor). Other
causes of worry are that the metaphor is misleading and implies relations that do not

---

exist, and also that the metaphor limits the conception of the system and provides no
insight on how to deal with changes once the system needs updating [3, 13].
Although the pratice is under scrutiny, system metaphor is often simply ignored.
The Extreme Programming Applied authors Ken Auer and Roy Miller also seem to feel
the same way in the chapter “Painting a Thousand Words”:
A lot of people doing XP say they haven’t really found a good metaphor
or that they use metaphors only for certain parts of the system. All of the peo-
ple we’ve talked to who don’t use a metaphor haven’t seen it as a significant
problem [8].
Within XP, then, experience with metaphor is somewhat mixed. Outside XP, how-
ever, metaphor is widely recognised as a fundamental part of communication. Not only
is metaphor used extensively in literature, art, film and everyday speech, it is a tried and
true learning technique which people use very frequently. To harness the benefits of
metaphor, in this paper we set out to improve understanding of XP metaphor, by draw-
ing upon existing theories of metaphor (in section 3) and then applying those analyses
to the use of metaphor in extreme programming (in section 4).
3 Semiotics
Agile software development is a relatively new methodology, forged out of the need for
adaptivity, faster software delivery time and communication. In particular it stresses the
need for face to face discussions between team members, and between team and cus-
tomer instead of relying on formal documentation. For these reasons, semiotics seems
like an ideal tool for studying and analysing XP system metaphor, as it is rigourous
enough to facilitate structured analysis, while still retaining enough flexibility to recog-
nise that multiple view points exist, and that views change over time.
By applying semiotics to XP metaphors, it is possible to harness a great amount of
work done in the general field of semiotics. Here, we present only enough background
to support our analysis of System Metaphor, as general introductions to semiotics are
widely available [16–20].
Note that we do not expect XP developers to use semiotics directly to analyse their
own metaphors. Rather, we will provide a structural model of the System Metaphor
practice, which is grounded in semiotics. Currently there is no such way to view and
understand metaphor, therefore the model will supply guidelines of sorts for developers
to understand, develop, and evaluate the metaphors that they build into their systems.
3.1 Peircean Semiotics
Semiotics is the formal study of signs. According to Charles Sanders Peirce, one of the
founders of semiotics, a sign is “something which stands to somebody for something in
some respect or capacity.” [21, v.2 p.228]; more succinctly, Umberto Eco has defined
a sign as “something that stands for something else” [18]. In other words, a sign can
be almost anything — footprints, written words, spoken words, thoughts, images —
anything which can mean something to someone.

---

Peirce proposed a triadic model of the sign. In his view, the sign is divided into
three parts: the object or referent, the representamen and the interpretant. While Peirce
made use of the term object, in this paper we shall use the term referent to avoid con-
fusion with objects from object-oriented programs. Figure 1 shows the representamen,
referent, and interpretant of a traffic “stop” sign.
Representamen:
STOP
Referent:
Interpretant:
cars must stop
"I should stop
here
my car"
Fig. 1. A diagram of the Peircean triad as applied to a stop-sign.
As is shown in the diagram, the representamen is the actual embodiment of the sign.
In this case, the sign in the world: a red octagon with the word “stop” written on it in
white block letters. The representamen is the part of the sign that people encounter and
attempt to understand the overall sign through.
The referent of the sign is the concept cars must stop here. This is the idea that the
sign is meant to convey to those who encounter it. Other ways of expressing this are
that the referent represents that concept or that it refers to that concept.
Finally, the interpretant of a sign is the thought or concept that occurs in an inter-
preter’s mind when they encounter the sign. Thus, in the figure, the person who has
encountered the sign correctly thinks that they should stop their car. There is no guaran-
tee, of course, that this “correct” interpretant will be arrived at. The person could have
thought something like “I should stop smoking my cigarette now.” Context, convention,
and law render this outcome unlikely, however.
One of the characteristics of Peircean semiotics that makes it particularly suitable
for modelling metaphor is that interpretants can act as representamens for new signs.
This type of process occurs very commonly as it takes place whenever people have
“chains” of thoughts. Joined signs indicate the process of refinement of a conveyed
concept.
3.2 The Semiotics of Metaphor
As a general figure of speech, “metaphor” has a reasonably broad scope of meaning.
For example, the Oxford English Dictionary defines metaphor as:

---

A figure of speech in which a name or descriptive word or phrase is trans-
ferred to an object or action different from, but analogous to, that to which it is
literally applicable [22]
More briefly, Lakoff & Johnson have defined metaphor as “understanding . . . one thing
in terms of another” [23]. A metaphor sign involves the interaction, in some way, of
the tenor and the vehicle of the metaphor, where the tenor is the thing or concept being
described, and the vehicle is the thing or concept that is used to describe the tenor [24].
In the example JULIET IS THE SUN, Juliet is the tenor, and the sun is the vehicle.
Representamen:
Sun
Metaphor
Introduction
Referent:
Interpretant:
Juliet
Juliet is the sun
Fig. 2. A semiotic model of metaphor introduction.
We use the Peircean sign to model the parts of the metaphor, shown in figure 2.
This Metaphor Introduction sign introduces the metaphor and places the vehicle and
tenor into context. The representamen of the sign consists of the vehicle of the chosen
metaphor, as it is easy to imagine that the vehicle “represents” the tenor. In the example,
the sun is the representamen. The referent of the sign is the tenor of the metaphor, as it
is the concept being referred to by the vehicle, and the relationship between the repre-
sentamen and referent is one of reference. In the example, Juliet is the referent, as the
sun represents, refers to, or stands for Juliet. Finally, the interpretant of the sign is the
complete metaphor, as it is an interpretation that a viewer may arrive at upon encoun-
tering the representamen in the context of the referent. It is a denotative interpretant,
which is to say that its meaning is embodied within its face value. The interpretant in
our example ends up as “Juliet is the sun”.
Representamen:
Juliet is the sun
Metaphorical
Entailments
Referent:
Interpretant:
Juliet's shining eyes
Juliet's eyes shine like sunbeams
Fig. 3. A semiotic model of metaphorical entailments.
Lakoff & Johnson carried out substantial work in the area of metaphor, and intro-
duced the concept of metaphorical entailments [23]. A metaphorical entailment is an

---

application of some fact about the vehicle of the metaphor to the tenor of the metaphor.
For example, if we consider the metaphor JULIET IS THE SUN, bearing in mind that
it was Romeo who made this statement, one of its metaphorical entailments might be
that “Romeo’s world revolves around Juliet”, because elements in solar systems revolve
around the sun, and this quality gets transferred to Juliet. Another entailment could be
that “Juliet gives Romeo life”, as many facets of life are dependent on the sun. While
a metaphor makes a direct comparison between tenor and vehicle, metaphorical entail-
ments consist of all of the indirect resulting qualities we can deduce about the tenor
based on the vehicle.
Semiotically, we model these entailments as instances of a second sign, the Metaphor-
ical Entailment sign, depicted in figure 3. The representamen of the metaphorical en-
tailment sign is the interpretant of the metaphor introduction sign, e.g. “Juliet is the
sun”. The referent of the metaphorical entailment sign is what the representamen refers
to or stands for, typically some characteristic, distinguishing mark or trait of the tenor
of the metaphor. The characteristic in this example is “Juliet’s shining eyes”. The in-
terpretant of the metaphor entailment sign is the result of reflecting upon the metaphor,
which (in this case) could be part of the meaning Romeo ascribes to the metaphor.
This entailment is typically closely tied to a characteristic embodied in the referent. For
example, “Juliet’s shining eyes”, which is a characteristic of Juliet in the opinion of
Romeo, is closely related to the statement “Juliet’s eyes shine like sunbeams”, which is
an entailment of the metaphor.
The difference between the characteristic and the entailment is that while the char-
acteristic describes the tenor independently of the vehicle, the entailment explicitly re-
lates qualities of the vehicle to the tenor. To contrast the interpretant of this sign with the
interpretant of the Metaphor Introduction sign, this interpretant is connotative, which
means that its meaning is dependent on cultural and personal associations.
Semiosis (the process of interpreting signs) can involve one sign leading to another,
as the interpretant of one sign can then become the representamen of another. In this
way, any sign has a generative capability. In the case of metaphor, the generative nature
works in a particularly sweeping way. The metaphor introduction sign can lead at once
to many instances of a metaphorical entailment sign. This actually happens because
domains of discourse are already rich with referents relating to characteristics of the
initial introduced metaphor. So, for example, Romeo’s world is full of referents relat-
ing to Juliet, her face, eyes, hair, personality, and so on, all ready to become referents
for metaphorical entailment signs. In such a world, a good metaphor introduction sign
becomes a fast-working factory generating metaphorical entailment signs.
Although the figure shows only a single characteristic as the referent and a sin-
gle resulting metaphorical entailment, this does not mean that the metaphor just refers
to this specific characteristic and entailment. In fact, any other characteristic of Juliet
could have replaced the one in the figure. Semiosis can be carried out repeatedly within
the metaphor, each time with a different referent, or characteristic and resulting en-
tailment. In this way, the metaphor model illustrates that a range of entailment signs
can be generated from an introduction sign, indeed the group of generated signs are
interrelated. In the example, from the viewpoint of Romeo, one characteristic of Juliet
is “Juliet’s shining eyes”. Equally, the characteristic could have been “Juliet’s beauty”

---

(noting that shining eyes might presuppose beauty), and then the resulting entailment
might be “Juliet is radiantly beautiful” as radiance is commonly associated with the sun
and its rays.
To summarise, a metaphor begins by describing its tenor in terms of its vehicle, with
this implied comparison giving rise to a range of metaphorical entailments. Both the
metaphor itself and the entailments can be taken as signs, which we call the metaphor
introduction and metaphor entailment signs respectively. The two signs are linked by
the chain of semiosis, as the interpretant of the metaphor introduction sign becomes the
representamen for the metaphorical entailments. Figure 4 shows our complete struc-
tural model of metaphor. Our model shows how metaphors convey meaning: a repre-
sentamen is used to describe a referent, and they become bonded as an interpretant. In
fact, the bonding process occurs repetitively for a range of referents, allowing charac-
teristics of the original referent to become interpreted in new ways, in effect generating
new, interrelated signs. These signs each relate characteristics of the original referent to
characterstics of the original representamen, according to the associative model of the
metaphor.
Representamen:
Sun
Metaphor
Introduction
Referent:
Interpretant:
Juliet
Juliet is the sun
Representamen:
Juliet is the sun
Metaphorical
Entailments
Referent:
Interpretant:
Juliet's shining eyes
Juliet's eyes shine like sunbeams
Fig. 4. A semiotic model of metaphor showing one particular entailment
3.3 Computing Semiotics
Given that questions of representation and interpretation undergird much of computer
science and software engineering, there is great potential for application of semiotics to
these areas. Much of the study that has been done in this area has been directed to the
design and analysis of user interfaces, because these are the most visibly sign-intensive
parts of a computer system, but there has also been work on software internal design,
and on broader issues relating to system development.
implementation and on system development at more general. [25, 26].

---

User-Interface Semiotics Metaphors are a very popular approach to user-interface
design [27–29], since being popularised by the Xerox Star and Apple Macintosh [30,
31]. A user-interface metaphor explains some system functionality or structure (the
tenor) by asserting its similarity to another concept or thing already familiar to the
user (the vehicle). The key to UI metaphors is that the chosen vehicle is something
already familiar to the user and so the intention is to provide a base level of comfort
and knowledge without necessarily understanding the underlying system.
There has also been work in semiotic models for user interfaces [26]. We ourselves
have have conducted a semiotic analysis of user-interface metaphors, again relying on
Peircean semiotics [32, 25]. The resulting semiotic structure is very similar to that of
figure 4, with a Metaphor Introduction sign giving rise to a series of Metaphorical En-
tailments. For user interface metaphors, of course, the representamen (vehicle) of the
metaphor is typically a word or graphical icon, such as a file folder or trashcan, while
the referent (tenor) of the metaphor is the system function they seek to present to users,
such as storing or deleting data.
Software Development Semiotics We have also applied semiotics to programming,
in particular to the analysis of design patterns. As code structures that stand for design
ideas, patterns can be treated directly as signs [33] and this can lead to an effective
categorisation scheme for patterns [34].
Peter Bøgh Andersen and colleagues have conducted extensive work focusing pri-
marily on computer systems in general, including both interface design and software
design. In his major work, A Theory of Computer Semiotics, Andersen develops an ex-
tensive theory on how semiotics can be applied to all aspects of computing [35]. The
book includes an extensive case study of the application of his methods to a software
system for a post office. Other important work by Anderson focusses on whether semi-
otics is a good approach to human-computer interaction at all [36].
Studies have been made applying semiotics to broader views of information systems
development using traditional development processes. For example, Marcelo Pimenta
and Richard Faust have taken a semiotic approach to requirements gathering [37], and
Liu and Stamper describe system design techniques explicitly based on semiotics [38,
39].
More generally still, we must remember that software development happens in con-
text of wider organisational activity. Organisational Semiotics provides a useful frame-
work for understanding this wider view. Stamper [40] provides an overview, and shows
how understanding system development involves both technical and organisational con-
cerns. The framework known as the “semiotic ladder” shows how these concerns can
be considered as levels of discourse stepping from technology to a human organisation
focus. We discuss further below how this relates to the XP practice involving system
metaphor.
An Object-Oriented Programming Sign Semiotics can also be used to describe
object-oriented programming [41, 34]. Within the Scandinavian approach, as described
by Ole Lehrmann Madsen, Birger Møller-Pedersen and Kristen Nygaard in Object-

---

Oriented Programming in the BETA Programming Language, programming is seen as
modelling the world:
A program execution is regarded as a physical model, simulating the be-
haviour of either a real or imaginary part of the world [42].
Programs are often written in a way that reflects similarities in state and behaviour be-
tween program objects and their users’ or customers’ domains; certainly programmers
have been taught to write their programs in this way for quite some time [43, 44].
Eyoun Eli Jacobson [45] explains this type of OO modelling as using objects and
classes featuring elements and references within the system and representational world,
to represent relevant phenomena and concepts exhibiting similar elements and refer-
ences within the system and conceptual world. For example, consider a Phone Book
object, where a Map object is being used to implement a telephone directory. The Map
object represents the Phone Book, while the binary search used within the Map repre-
sents looking up something in the book.
We can describe this relationship using semiotics, as shown in figures 5 and 6. We
call these signs “Object-Oriented Programming” signs, because they capture the ba-
sic semiosis that is typically latent in object-oriented programming. In each of these
signs, the representamen is the program element standing in as a representation (the
map object or its lookup method), the referent is the domain concept being represented
(phone book or lookup) and the interpretant of the sign establishes the representational
relationship between the program object and the external object — the idea that this
particular map object represents that particular phone book; that this particular binary
search lookup method represents searching the phone book.
Representamen:
Map object
Referent:
Interpretant:
Phone Book
The Phone Book is like a
Map object
Fig. 5. An OOP sign for an Address Book object
4 A Structural Model of the XP System Metaphor
Extreme Programming system metaphors are indeed metaphors: they describe one thing
in terms of another. XP system metaphors are a specialised case of metaphor, how-
ever, in that they specifically serve to describe object-oriented software systems. We
therefore model XP system metaphors by combining our semiotic models of general
metaphors and of object-oriented systems, as shown in figure 7. This model of XP sys-
tem metaphors consists of three interrelated signs. The first sign introduces the parts of

---