Annals of Software Engineering 10 (2000) 273–292 273

Metaphor, myth and mimicry:

The bases of software engineering
Antony Bryant
School of Information Management, Leeds Metropolitan University, Beckett Park, Leeds LS6 3QS, UK
E-mail: a.bryant@lmu.ac.uk

The term software engineering has had a problematic history since its appearance in
the 1960s. At first seen as a euphemism for programming, it has now come to encompass
a wide range of activities. At its core lies the desire of software developers to mimic
‘real’ engineers, and claim the status of an engineering discipline. Attempts to establish
such a discipline, however, confront pressing commercial demands for cheap and timely
software products. This paper briefly examines some of the claims for the engineering
nature of software development, before moving to argue that the term ‘engineering’ itself
carries with it some unwanted baggage. This contributes to the intellectual quandary in
which software development finds itself, and this is exacerbated by many writers who rely
upon and propagate a mythical view of ‘engineering.’ To complicate matters further, our
understanding of software development is grounded in a series of metaphors that highlight
some key aspects of the field, but push other important issues into the shadows. A re-
reading of Brooks’ “No Silver Bullet” paper indicates that the metaphorical bases of software
development have been recognized for some time. They cannot simply be jettisoned, but
perhaps they need widening to incorporate others such as Brooks’ concepts of growth and
nurture of software. Two examples illustrate the role played by metaphor in software
development, and the paper concludes with the idea that perhaps we need to adopt a more
critical stance to the ‘engineering’ roots of our endeavours.1

1. Introduction

. . . a new subdiscipline, software engineering, has arisen. The development of

a large piece of software is perceived as an engineering task, to be approached
with the same care as the construction of a skyscraper, for example, and with the
same attention to cost, reliability, and maintainability of the final product. The
software-engineering process is usually described as consisting of several phases,
1
I should like to express my thanks to the anonymous reviewers of the first draft of this paper. Two
of them offered useful advice to enhance the finished version; the third gave vent to a perfectly valid
concern, that the argument as stated could have grave side effects if it was used as a point of leverage in
arguments over ownership of the term ‘engineering.’ I understand this concern and the potential financial
implications that prompt its expression; but in the longer term I see this exercise in clarification as a
contribution to such discussions, inasmuch as it helps defuse the potency of terms such as ‘engineering.’

 J.C. Baltzer AG, Science Publishers

274 A. Bryant / Metaphor, myth and mimicry

variously defined but in general consisting of (1) identification and analysis of user
requirements, (2) development of system specifications (both hardware and soft-
ware), (3) software design (perhaps at several successively more detailed levels),
(4) implementation (actual coding), (5) testing, and (6) maintenance. Even with
such an engineering discipline in place, the software-development process is expen-
sive and time-consuming. (An extract from the entry on software engineering, a
subsection of the entry on “Computer Science: Software,” in the CDROM version
of the Encyclopaedia Britannica.)
Current discussions rage in the UK regarding the nature and location of “Software
Engineering”. This is not merely a matter of semantics, but has organizational and
financial implications, not least the allocation of research funding. In a wider sense
the nature of the discipline of software engineering – if it can claim to be one – and
its relationship to computer science, information systems and other areas of study has
always been a contentious issue; with ramifications in terms of training, curriculum
issues, career development, funding, professionalism (particularly, in terms of visibility,
certification and recognition), and practice, in addition to any specific knowledge claims
as a distinctive discipline.
The term ‘software engineering’ is in itself problematic. Originating in the late
1960s, in the 1980s it seemed to be a ‘good thing.’ Software production had to be
seen to encompass more than ‘programming,’ since the latter conjured up the image of
the computer geek, hacking code that could potentially lead to wonderful results, but
all too often led to software that was delivered late, at a cost far in excess of budget,
and generally unfit for purpose. The idea that software had to be ‘engineered’ evoked
an image of rigour, care and assurance.
Professional qualifications and university courses emerged with ‘software engi-
neering’ as the key component of their title and content; and such courses seemed
to offer a more pragmatic understanding of computer technology than did the more
traditional computer science courses. In practice, however, it soon became clear that
the situation was not quite as simple. The term was often misunderstood, and some
university courses found it difficult to recruit to such courses as many potential appli-
cants were misled by the term itself. Although several standard student texts appeared
– e.g., Somerville and Pressman – there was still an air of unease around the term and
its associated terminology. In the late 1990s there is perhaps a consensus around the
term itself within the academic and research community, but as a specific course title
its popularity and use is declining.
Recent discussion threads on the electronic list from the (UK-based) Conference
of Professors and Heads of Computing (CPHC) illustrate this all too cogently. For
various reasons the CPHC have had to produce details of what is involved in research
into and the study of computing, informatics, software engineering and so on. In most
instances an uneasy consensus has been reached, but all too often with the nagging
suspicion that this agreement is only understood by the senior academics concerned,
and will be misinterpreted by those outside this restricted domain: In particular by the
 A. Bryant / Metaphor, myth and mimicry 275

wider engineering community, funding organizations, practitioners, potential students,

and commercial developers.
Here we have the dilemma: Software developers want to mimic the engineers,
and lay a claim for the status of an engineering discipline; but commercial demands
and consumer desires do not support this. In what follows I wish to argue that perhaps
the term itself carries with it some unwanted baggage, and consequently contributes
to the intellectual quandary in which software development finds itself.

2. Software engineering defined and critiqued

Sommerville in the latest edition of his standard text defines software engineering
as being “concerned with theories, methods and tools which are needed to develop
software for . . . computers.” He distinguishes between software engineering and other
forms of engineering since the former “is not constrained by materials governed by
physical laws or by manufacturing processes” [Sommerville 1996, p. 4].
Pressman quotes Fritz Bauer from the 1968 NATO conference as follows – soft-
ware engineering is the “establishment and use of sound engineering principles in order
to obtain economically software that is reliable and works efficiently on real machines”
(quoted in [Pressman 1992, p. 23]). Pressman stresses the need for “engineering dis-
cipline in software development.”
McDermid, in his introduction to the Software Engineer’s Reference Book points
out that “[I]f software engineering is to become a true discipline it too must have an
appropriate foundation in science and mathematics” [McDermid, 1991, p. 1].
Clearly there is a consensus that software development needs a rigorous basis,
and that this is to be found in engineering, and indirectly in science and mathematics.
I suspect that most readers will find nothing exceptional in such statements. For far
too long software development was allowed to proceed with little or no constraint,
and so the application of an immediately appealing and intuitively obvious archetype
or exemplar needs little or no justification. But what do all these writers mean when
they talk of ‘engineering’? Are they suggesting that software development can benefit
from simply mimicking engineering? McDermid stresses the need for a foundation
in science and mathematics. Pressman, quoting Bauer, talks simply of ‘engineering
principles’, which might incorporate theoretical principles – and so include science and
mathematics – but which might also hint at principles related to engineering practice.
Sommerville includes ‘theories, methods and tools’ which seems to cover both the
theoretical and practical aspects; but he also makes the point that software engineering
is distinct from other forms of engineering because of the nature of software itself.
In the mid 1970s Tony Hoare addressed precisely these issues [Hoare 1975].
He sought to define the key components of ‘engineering’ that made it a worthwhile
and relevant goal for software developers to mimic. He identified four aspects of
engineering which cover both the theoretical aspects of software engineering and the
issues concerned with practice:
276 A. Bryant / Metaphor, myth and mimicry

• professionalism,
• vigilance,
• sound theoretical knowledge, and
• tools.

Although his descriptions of these terms, and their applicability to non-software

engineers, seem a trifle idealised, they certainly illustrated his argument that software
engineers were deluding themselves if they thought that their current (1970s) position
offered any foundation for their claim to the status of real engineers.2
Some 25 years later Hoare’s criticisms retain their cogency. Perhaps there is a
semblance of professionalism amongst software developers. There has been a steady
growth or accumulation in the theoretical knowledge surrounding software develop-
ment, but its application and overall relevance might be disputed. Tools have certainly
advanced, although their actual use and level of reliability continue to vex practitioners.
Vigilance remains a problem. Hoare defined it as including cost-effectiveness, striv-
ing for elegance and simplicity in concept, specification, design and implementation;
together with continued control during development.
Since Hoare’s article first appeared, over 20 years ago, the nature of software
engineering has undergone a transformation as the technology itself has developed.
These developments have been summarised by Wasserman [1996] who points to seven
key changes that have impacted on software engineering practice:

• Criticality in the time-to-market for commercial products.

• Changing economics of computing – lower hardware costs, greater development
costs.
• Emergence of powerful desk top computing.
• Extensive local and wide area networks – especially the web as publishing and
distribution mechanism.
• OO Technology – growing in availability and acceptance.
• WIMPS and GUIs.
• Unpredictability of waterfall model of software development (inapplicability seems
a more accurate term for Wasserman’s argument).

Wasserman argues that any one of these developments would have had a signifi-
cant impact on the software development process; but taken together they have resulted
in a major transformational force. Software engineering in the 1990s cannot be an ex-
tension of what it was in the 1970s, if it is to retain relevance to current software
development it has to make a quantum leap from its origins. In so doing, software
engineering theory and practice have to focus around the fundamental principles of an
2
I do not wish to go into the full account of Hoare’s argument at this juncture. The original from 1975
is still well worth reading, and I have commented on it in an earlier paper [Bryant 1989].
 A. Bryant / Metaphor, myth and mimicry 277

‘effective discipline.’ Wasserman suggests that there are eight fundamental notions in
software engineering “that form the basis for an effective discipline:”
• Abstraction – a key aspect for focusing on relevant detail – “fundamental technique
for understanding and solving problem.”
• Analysis & Design Methods and Notations – for communication, a basis for check-
ing and reuse – “basic tools for communication in an engineering discipline.”
• User Interface Prototyping – for requirements determination, assurance, feasibility
– the “most effective way to elicit user requirements.”
• Modularity and Software Architecture – reflecting principles of ‘good design’, in-
cluding decomposition, different perspectives – this plays a “major role in deter-
mining system quality and maintainability.”
• Lifecycle and Process – with a matching of process to different goals and contexts
– “having some defined and manageable process for software development is much
better than not having one at all.”
• Reuse – including more than just code; and covering aspects such as responsibil-
ity for any reused component – “an essential part of any software development
process.”
• Metrics – “improvements . . . cannot be calculated without an effective metrics
effort.”
• Tools and Integrated Environments – “should provide comprehensive and integrated
support for the development process” [Wasserman 1996, p. 24].
Pfleeger [1998] suggests that these eight aspects be seen as threads woven into the
fabric of software engineering. In the light of Hoare’s criticisms, and the definitions of
software engineering mentioned earlier, we might ask in what ways would progress in
terms of any or all of these eight result in the firm foundation of a truly engineering-
based discipline of software development? Are the eight necessary and sufficient to
provide this foundation?
But then a further series of questions arise:
• Is it possible that we are inevitably going to fall well short of the heights to which
we aspire when we talk about software engineering?
• Are we pursuing the right goal when striving for engineering status?
• Are we trying to attain it in an appropriate manner?
The sorts of discussion that arise periodically in the literature regarding the nature
of software engineering are not in any way symptomatic of a critical deficiency in
software engineering. On the contrary they can be seen as evidence of an emerging and
vibrant discipline that has perhaps yet to establish itself, and where there is opportunity
to influence its nature and scope. What does need to be demonstrated, however, is
the existence of some problematic issues that arise from the (often unquestioned)
bases of software engineering itself: In particular the ways in which the terminology
278 A. Bryant / Metaphor, myth and mimicry

and imagery in currently use may influence our understanding of the domain and its
associated practices.

3. F.P. Brooks – accidents, essences and metaphors

F.P. Brooks in his classic paper “No Silver Bullet” [Brooks 1987], illustrates the
dilemma of software engineering. Software is the most complex human artefact and
also the most intangible. His four ‘essences’ – complexity, changeability, conformity,
and invisibility – are now part of the lore of software engineering. These Aristotelian
essences are characteristics of software that are ineluctable. Software engineering
practices must contend with these, although they can never be completely evaded. On
the other hand, software development is also beset by a variety of historical accidents.
These accidents are not an indelible aspect of software, but arise from prevailing
technology and practices: As such they can and usually will be overcome.3 What
Brooks does not mention – but also does not rule out – is that new historical accidents
may arise.
So we have a range of activities concerned with the production of complex
human artefacts, where many of the usual possible conceptual and practical support
mechanisms are unavailable. We cannot build scale models, we cannot demonstrate
key aspects of the processes involved; and once software is produced, it is unlikely
that it can be stabilized. It will constantly be changed to yield to demands for it to
be altered to adapt to changing requirements and contexts. No wonder that software
developers apply terminology borrowed from elsewhere, or create new terms closely
related to those from other contexts. This inevitably results in software development
being described and defined in terms of metaphors borrowed from other disciplines.
In sum we have a ‘discipline’ that has emerged within the last 30 years now
vying for a place in the world; particularly with regard to academic funding, research,
general recognition and professional certification. The scope and topic of this discipline
is the range of skills, techniques, and specialisms for the development of software-
based systems – but software itself remains elusive for all the reasons put forward by
Brooks.
As part of this emergence of a new discipline, there has been a growing consen-
sus to mimic and take on the trappings and imagery of engineering. Thus we have
aspects of software development concerned with maintenance, prototyping, construc-
tion, specification, design and so on. (Numerous other examples may be found in the
standard texts, handbooks, etc.)
Brooks himself expressed some uneasiness with this imagery. He noted the impact
that the construction metaphor had on him when he first came across it in 1958. “The
metaphor shift was powerful, and accurate. Today . . . we freely use other elements
of the metaphor, such as specifications, assembly of components, and scaffolding”
[Brooks 1987, p. 18]. He then went on to argue that, although useful and powerful,
3
I do not feel the need to reiterate the details of Brooks’ argument to this readership.
 A. Bryant / Metaphor, myth and mimicry 279

this construction metaphor had outlived its usefulness, and needed to be replaced by
an image of software development more akin to growth than construction.
It is important to stress a number of features in Brooks’ argument. When he
discusses the impact of the building metaphor he talks about a ‘metaphor shift’: In
other words the replacement of one metaphor by another. He takes it as axiomatic that
metaphors operate with regard to software development, and he sees the shift as one
from writing software to building software. Furthermore, he implies that metaphors
have a powerful impact on people’s practices and cognition. The terms used are not
simply words on a page, they have significant effects, as Brooks asserts – “I have
seen dramatic results since I began urging this technique (the growing of software
using incremental development) on my project builders in my Software Engineering
Laboratory class” [Brooks 1987, p. 18]. He continues in a similar vein, mentioning
heightened morale, jumps in enthusiasm, redoubled efforts and so on. He concludes
that “teams can grow much more complex entities in four months than they can build.”
If Brooks is correct in assessing the impact of this new metaphor, does it mean
that the older metaphors are now operating as constraints on software development
practices? Is the term software engineering itself now an obstacle? Is it possible that
the engineering metaphor is actually part of the ‘software crisis’ rather than a solution
to it?
One of the lessons to be learned from Brooks’ argument is that there will always
be a ‘software crisis.’ He presents the argument that the cause of many of the problems
lies with the nature of software itself. But that is not to say that other, less intrinsic
factors, are not important: And these can be confronted and eradicated – they arise
from historical accident. Thus the term software engineering itself may be one of these
constraints, and we may have to confront the possibility that mimicry of engineering,
particularly in the form of the widespread acceptance of the engineering metaphor,
exacerbates some of the key issues in software development itself.
This is not to suggest that mimicry and metaphor alone – or even substantially
– lie at the root of the problematic issues in software development; but it is to argue
that software engineering is a discipline justifiably founded on metaphor, but now
perhaps beginning to flounder on metaphor. Perhaps it is time to consider jettisoning
the engineering metaphor altogether, or at least recognizing its unintended, but potent,
consequences.

4. Metaphors in general and the engineering metaphor in particular

The activities surrounding software and software development are usually defined
in terms of the ‘engineering metaphor.’4 The metaphor extends to use of terms such
as construction, development, maintenance, prototyping, and so on. This terminology
4
For the purposes of this discussion, metaphor will be taken to mean a “figure of speech in which a
name or descriptive term is transferred to some object to which it is not properly applicable” – Shorter
OED, 1973.
280 A. Bryant / Metaphor, myth and mimicry

and imagery can be simultaneously intuitively obvious and accompanied by numerous

caveats. Thus it is common for software developers to talk about maintaining software,
but they are usually well aware that this use of the term is peculiar in this context, and
only partially resonates with the mainstream engineering use: Similarly with terms
such as prototyping.
It may appear that this imagery is now so ingrained in the discipline that it
can hardly be controversial. Students, teachers and practitioners all know that the
language used is not a direct translation from mainstream engineering; so why raise it
as an issue? Can the engineering metaphor really have a profound impact? Is this a
common characteristic of metaphor?
Metaphor might be thought of as a restricted linguistic device, usually (con-
sciously) employed for its dramatic effects. But this is an inadequate view, and
severely underestimates the role that metaphor plays in our lives. Fowler’s [1965]
Modern English Usage notes that “our vocabulary is largely built on metaphors; we
use them, though perhaps not consciously, whenever we speak or write.” This attests
to the ubiquitous nature of metaphors, but not to their role in our thought processes.
They may be pervasive, but for Fowler/Gowers in the 1960s they are passive. In
recent years, however, this argument has been challenged, and there is now a wide-
spread view that metaphors play an active role in thought and cognition. In particular,
metaphors are now seen as a crucial aspect in the spread and understanding of new
ideas and concepts.
How do metaphors operate? Any metaphor has two distinct subjects; a ‘primary’
and a ‘secondary’.5 In the instance of software engineering, the primary subject is
software, the secondary is engineering. Black [1993, pp. 27–28] stresses that “the
secondary subject is to be regarded as a system rather than an individual thing.”
In other words, the term engineering is not used in isolation; but evokes a whole
range of concepts and terms involved in the engineering frame of reference. The
metaphorical utterance then works by “projecting upon the primary subject a set of
associated implications . . . that are predicable of the secondary subject.”
Black uses the example of “society is a sea”; but for our purposes we can con-
sider the phrase software development is an engineering discipline. This relationship
between the primary and secondary operates in the following manner:
• the presence of the primary subject incites the hearer to select some of the secondary
subject’s properties; and that
• invites the hearer to construct a parallel implication-complex that can fit the primary
subject; and
• reciprocally induces parallel changes in the secondary subject.
Note that this view of metaphor depends on selection by the hearer/reader
of aspects of the secondary subject; and that this also leads to changes in the
5
This overview of metaphor is based largely on Max Black’s essay in [Ortony 1993]. Many of the other
ideas introduced later derive from other contributors to the collection edited by Ortony.
 A. Bryant / Metaphor, myth and mimicry 281

hearer’s/reader’s conception of the secondary subject. If we expand the engineer-

ing metaphor to be stated as “software development is an engineering discipline,” then
according to Black we select aspects of engineering to fit software development, and
also reinterpret engineering as a result of applying its properties to software develop-
ment. Perhaps this partially explains why it is that non-software engineers never seem
to get to grips with what software engineers mean by engineering!
Stated in this form, we are probably expected to understand that engineering is
a discipline, with all that is implied in terms of rigour, knowledge claims, expertise
and so on; and that software development can be considered in a similar fashion. The
metaphor might then operate in terms of identity, extension, similarity, analogy, and
metaphorical coupling (linking a series of metaphors). For Black “every metaphor is
the tip of a submerged model” [Black 1993, p. 30].6 Thus the engineering metaphor
for software development implies a model of software development practice. This
model might take the form of seeing software development actually as an engineer-
ing discipline; as like an engineering discipline; or as bearing some similarity to an
engineering discipline. Examples of each can be found across the standard texts and
handbooks. Furthermore, the articulation of this model will impact upon the conceptu-
alisation of engineering itself: If Black’s argument is correct, software engineers will
understand engineering differently in the light of the use of the metaphor in the realm
of software development. This would make an interesting research project, and could
now be extended to other domains from which we have borrowed metaphors – e.g.,
architecture and design.
It should be stressed that there is no single, ‘correct’ model of software develop-
ment that emanates from the engineering metaphor, although with time – and stability
– a consensus may emerge. At present there exists a range of interpretations, and
these different interpretations evoke a variety of models of what constitutes software
development. We need to recognize the nature and characteristics of these models;
uncovering their ramifications, similarities and distinctions to ensure that they are ap-
propriate and relevant. This is not simply a matter of terminology; the engineering
metaphor itself plays a cognitive role for software development. So we need to clarify
the impact of this metaphor on the practices of software development, and to ascer-
tain if alternative metaphors might not be more appropriate, or remedy any of the
deficiencies of the engineering one.

5. Metaphors and cognition

It is crucial to reiterate Brooks’ point about a metaphor shift: Implying that

the construction metaphor (a specialised case of the engineering one) did not simply
emerge in a context where no previous metaphor had existed. There was no literal
understanding of software development prior to the 1960s; the preceding dominant
metaphor was concerned with writing software.
6
Note the metaphor!
282 A. Bryant / Metaphor, myth and mimicry

Whether or not all cognition has to employ metaphor, an argument that goes
well beyond the scope of this paper, it certainly seems to be the case that metaphors
are indispensable in contexts of novelty and innovation. Black maintains that ‘strong
metaphors’ act as indispensable bases for generating new understanding or interpre-
tation of reality – “. . . I still wish to contend that some metaphors enable us to see
aspects of reality that the metaphor’s production helps to constitute” [Black 1993,
p. 38].
Metaphors serve in a powerful, creative fashion; producing genuine insight in the
manner Brooks’ suggests for both the construction metaphor and the growth metaphor.
It is hardly surprising that metaphors have played, and continue to play, such a critical
role with regard to software. The tension between its invisibility and intangibility on the
one hand, and its complexity on the other, almost demands metaphorical mechanisms
and allusions. In this sense metaphors are not simply some form of linguistic baggage
that obscures reality, they are actually crucial in constituting that reality: Although
this is not to deny that sometimes metaphors do indeed obscure, rather than illuminate.
Moreover this is not restricted to software, but applies to computers and computing in
general.
As Boulter notes, computers are “a defining technology,” which “develops links,
metaphorical or otherwise, with a culture’s science, philosophy or literature; it is always
available to serve as a metaphor, example, model or symbol” (quoted in [Berman 1989,
p. 7]). Likewise, Sherry Turkle, “computers are very special; we use human terms
to describe computers, and vice-versa” (quoted in [Berman 1989]). However, the
relationship between the technology and the metaphors is complex; as Weizenbaum
[1984, p. ix] has observed the “remaking of the world in the image of the computer
started long before there were any electronic computers”.

6. Metaphors as generative devices

Why does all this have any relevance to software engineering? Surely we can all
realize the inadequacies and limitations of the term? Surely all this linguistic baggage
is mere adornment, and has no substantive impact on the practices and processes of
software development itself? Based on my understanding of recent work on the power
and role of metaphor, I would argue that the language does have an impact, and
that it is critical for practitioners to recognize this; and, where necessary, remedy the
terminology. In turn this may well result in a reorientation of the theory and practices
of software development.
The creative aspect of metaphor is developed further by Schön [1993]. Schön
views metaphors as generative; explicitly undermining the idea that a metaphor is
a “kind of anomaly of language, one which must be dispelled in order to clear the
path for a general theory of reference or meaning”. He proposes that metaphor be
viewed as “central to the task of accounting for our perspectives on the world” [Schön
1993, p. 137]; and as such ‘metaphor’ must be understood both as a product and
as a process. Thus metaphorical utterances such as “software development is an
 A. Bryant / Metaphor, myth and mimicry 283

engineering discipline,” are symptoms of a process of “carrying over of frames or

perspectives from one domain of experience to another.” This is what Schön terms
‘generative metaphor.’
This leads to two issues: The hermeneutic one of interpretation and understand-
ing, including use of evidence and justification for particular a metaphor; the gener-
ativity one concerning the processes by which certain metaphors come into existence
and flourish, what Schön terms their ‘anatomy.’7
More critically for our purposes, Schön wants to direct attention to areas where
there are conflicting frames, demanding ‘frame restructuring.’ These are domains
where differences are not explicable or reconcilable by recourse to facts or fixes;
but which emanate from conflicting frames for the construction of reality, and where
the only recourse is to “restructuring, coordination, reconciliation, or integration of
conflicting frames” [Schön 1993, p. 139]. This is a process that is similar to the
making of generative metaphor.
Schön illustrates his argument with reference to a group of researchers seeking to
develop a new paintbrush. This new product used artificial bristles instead of natural
ones. The brush failed to give the same smooth finish as its bristle counterpart, leaving
a surface that was marked by discontinuous application of the paint. The group had
observed that bristles produced ‘split ends,’ whereas synthetic ones did not; so they
split the ends of the synthetic brush, but with no marked improvement. Real progress
was made, however, when one of the team remarked that “a paintbrush is a kind of
pump”; and that painting really amounts to using the spaces between the bristles as
channels through which the paint can flow. This directed their attention to a range of
new factors, such as the curve formed by the bristles of the non-synthetic brush. What
in strict terms might be thought of as a mistake – “a paintbrush is a pump” – results
in the generation of new perspectives, explanations and inventions.
Schön is keen to point out that this process is not simply one of ‘mapping’
from one domain (pumps) to the other (painting). The initial response is one of
‘unarticulated perception,’ only later might the relationship be clarified by interpreting
ostensibly different ‘tools’ as examples of a single category.
This is what Schön terms the life cycle of a generative metaphor. Initially “one
notices that A and B are similar, without being able to say similar with respect to
what.” Only later can the relationships between the two be described in a “restructured
perception of both A and B . . . an analogy between A and B.” Later still “one may
construct a general model for which a redescribed A and a redescribed B can be
identified as instances.”
If the paintbrush example seems trivial, Schön’s more extensive illustration con-
cerns housing policy: In particular, the conflict between those who see the issue of
7
Schön distinguishes between living and dead metaphors – thus examples of the latter might be “the foot
of the mountain”, “the leg of the table,” etc. So it might be thought that software engineering might
become such a dead metaphor. I would contend, however, that dead metaphors are never really dead,
they are just resting, waiting to be reawakened – e.g., one might revive “the foot of the mountains” by
talking of “struggling across the narrow neck of land between the foothills and the headlands.”
284 A. Bryant / Metaphor, myth and mimicry

urban housing in terms of “slum clearance and removal of urban blight,” and those
who see it in terms of “natural communities that must be protected or restored.” “It
is precisely because neighborhoods are not literally diseased that one can see them as
diseased. It is because urban communities are not literally natural that one can see
them as natural.”
Schön’s solution to frame conflict is what he terms “frame restructuring . . . con-
structing a new problem-setting story, one in which we attempt to integrate conflicting
frames by including features and relations drawn from earlier stories, yet without sacri-
ficing internal coherence or the degree of simplicity required for action” [Schön 1993,
p. 152].
Schön demonstrates that frame-restructuring and the making of generative
metaphor are closely related. “In both processes, participants bring to the situation
different and conflicting ways of seeing . . . there is an impetus to map the descriptions
. . . but [they] resist mapping . . . the participants work at the restructuring of their
initial descriptions – regrouping, reordering, and renaming elements and relations . . .”
[Schön 1993, p. 159].

7. An example – information technology

By now it should be clear what metaphors are, and how they operate as an in-
dispensable component of cognition. I believe this provides the justification to argue
that it is crucial to analyze and partially dismantle the engineering metaphor for soft-
ware development. Two examples offer a point of departure for this project. The
first one, IT, is fairly straightforward, but illustrates the ways in which terminology
produces barriers to understanding that in turn have widespread effects. The second,
requirements, is far more critical to software development practices.
As software development professionals and academics, many of us continually
do battle with the term IT, trying to make people understand that the technology – by
which we really mean the hardware – is not the true focus of the subject. Some of
us even try to get people to use the term information system (IS) in preference, but
usually to no avail. This is hardly surprising as, in the UK at least, academics can
never agree on the use of the term IS; some see it as an all-inclusive term, others see
it as entirely misleading and inappropriate. The problem is that the cognitive power
of the term IT stresses the technology part to the detriment of the information part.
A recent edition of the Insurance Technology Research Report [September 1998]
noted that “IT is the bottom of the career wish list.” Amongst men 69% dismissed
it as a career choice; amongst women it was even higher at 86%. Respondents were
concerned that IT was ‘too technical,’ and associated it as a career with nerds and
geeks, “clever but lacking in social skills.” This was partially explained by the link of
IT to science and computers, and the fact that in the media “scientists and computer
experts are portrayed [as] . . . brilliant but socially flawed and slightly mad.”
The same article went on to point out that the employers who participated in the
survey were most concerned at the lack of business and social skills amongst graduates;
 A. Bryant / Metaphor, myth and mimicry 285

and that this was the greatest concern among those recruiting to the IT sector. Some
even believed that the best equipped graduates for this sector were those who had not
studied IT.8
Although there are a whole host of influences and factors at work in this example,
the impact of the metaphor that lies behind the idea of information technology must be
acknowledged to have profound effects. In many cases simply substituting the term
‘business information’ in place of ‘information technology’ has had an immediate
impact in terms of recruitment to undergraduate courses, leading to a more varied and
gender-balanced intake. Similarly in many organizations, the use of the term IT leads
to non-IT people mistakenly seeing IT as simply a support aspect of organizational
activity; often a costly fallacy.

8. Requirements – capture, specification, engineering?

The second example is central and critical to software engineering. In numer-

ous surveys it is the requirements phase that is seen as the most important and the
most difficult. The standard texts usually view this in terms of the documents that are
produced during and at the end of this phase – e.g., requirements specification, require-
ments definition and so on. The current vogue seems to be to use the term requirements
engineering for the activities that lead to these products, although Sommerville [1996,
p. 64] notes that “the term engineering is used rather loosely.”
The terminology surrounding requirements for computer-based systems is replete
with references to the engineering metaphor. The terms requirements definition, re-
quirements specification, requirements validation, and so on may appear unremarkable
in the 1990s, but they derive from the engineering realm: Similarly the idea that a
good specification should be clear, concise, complete, and so on.
The assumption, often clearly stated, is that the requirements process must be
systematic, with some element of management and formality. So perhaps the use
of the engineering metaphor provides a useful basis for what is widely agreed to be
the most critical and disparate part of software development. This is, however, only
partially correct. The engineering metaphor itself reverberates beyond the ideas of
rigour and formality, with connotations that obscure key features of the process. This
is not a problem that is restricted to software engineering; it is far more pervasive.
In a remarkable paper Reddy [1993] discusses what he calls the conduit metaphor
– a metaphor deeply embedded in our ideas of communication (and I suspect it is not
restricted to English).
8
The term ‘technology’ is now understood to refer to something tangible – something you can kick!
Whereas originally it simply meant something connected with knowledge, and more specifically with
practice and method. So technology might itself be seen as operating on a metaphorical level; with the
original term having been a link between ‘know how’ and some artefact or invention that demonstrated
or embodied that know-how. The advent of IT has now displaced the original meaning completely, so
that technology now refers to the electronic components.
286 A. Bryant / Metaphor, myth and mimicry

Reddy poses the question ‘What do speakers of English say when communication
fails or goes astray?’ He then offers a series of examples. It will, however, be more
pertinent to consider the following, derived from a requirements exercise where the
clients’ and users’ views have not been fully understood by the developers; and where
the developers have not made clear the trade-offs and constraints to the domain experts:
1. The developers should try to get their thoughts across better.
2. None of the real issues about users’ demands came across to me with any clarity.
3. We have not given the domain experts a clear idea about the technological con-
straints.9
All these examples seem at first sight unremarkable, and devoid of metaphors.
Yet Reddy argues that all of them – and many more of their ilk – involve the idea that
information is transferred from one point or person to another. Good communication
then resembles friction-free, blockage-free flow. Good reception involves extraction
and unwrapping.
Reddy offers numerous examples before offering what he terms the four cate-
gories that constitute the critical features of the conduit metaphor:
(1) “language functions like a conduit, transferring thoughts bodily from one person
to another;
(2) in writing and speaking, people insert their thoughts or feelings in the words;
(3) words accomplish the transfer by containing the thoughts or feelings and conveying
them to others; and
(4) in listening or reading, people extract the thoughts and feelings once again from
the words.”
Reddy further points out that one sub-component of this conduit metaphor char-
acterizes thoughts and feelings as being “ejected . . . into an external ideal space:”
Where they are reified, and take on an independent existence; and from where they
may or may not “find their way back into the heads of living humans.”
Again some examples illustrate these features with regard to software develop-
ment:
1. Get those requirements down on paper before we lose them.
2. We’ve been trying to pin down that idea for ages.
3. There’s more than a head-full of issues here.
To demonstrate the impact and ramifications of this metaphor – or frame, to
use Schön’s ideas – Reddy offers an alternative: One which lends itself easily to the
software development context – “. . . in order to engage in frame restructuring about
9
These are broadly similar to the examples that Reddy himself offers [Reddy 1993, p. 167].
 A. Bryant / Metaphor, myth and mimicry 287

Figure 1.

human communication, we need first an opposing frame.” He offers what he terms

the toolmakers paradigm.
This paradigm is best understood through Reddy’s own example, and this needs to
be described at some length. He supposes that there exists a community of people living
in a compound shown schematically in figure 1. Each person has their own sector, and
no two sectors are alike. The hub of the wheel contains a mechanism for delivering
paper messages from one person to another, and this is crucial in people passing on
their ideas about how best to survive in terms of building shelters, developing tools,
and so on. People cannot visit each other’s sectors, nor can they exchange products;
only crude blueprints.
Any individual only knows about the existence of others as an inference from
the exchange of pieces of paper, plus other supporting deductions. Reddy calls this
the “postulate of radical subjectivity.”
Suppose that the person living in sector A develops a tool; a rake for clearing
away leaves and other debris. She goes to the hub and draws three identical sets of
instructions for fashioning this tool, leaving a copy for B, C and D. A’s environment
has a lot of wood and trees in it, but B’s sector is mostly rocky. So B tries to copy
the design for A’s rake, using a wooden handle and a stone head. A did not specify
the material for the handle or the head (which were both wood) since there seemed
no alternative. B completes the ‘rake’, but finds it unwieldy and heavy; and wonders
at the strength of A. Also he is somewhat bemused at the tool itself, and guesses
that A uses it to clear away small rocks in her sector. He improvises for his own
environment, and eventually decides that a better form of the tool will be one that
has two prongs to unearth large rocks. This is far more useful for B’s sector. B then
sketches out his tool design and makes three copies for the others to study.
Persons C and D develop their own tools on the basis of the plans from A and B.
Person A makes a tool along the lines suggested by B, but can see no use for it in her
own rock-free sector. She also wonders if B has misunderstood her original design,
288 A. Bryant / Metaphor, myth and mimicry

and so produces a more detailed one for circulation. The interchange between A and B
goes on for some time, until A comes across two small pebbles in her sector, and she
begins to understand that her assumptions about wooden materials and organic debris
may not be universally applicable. The result is that A and B raise “themselves to a
new plateau of inference about each other and each other’s environments.”
The fundamental difference between the toolmakers paradigm and the conduit
metaphor is that for the latter successful communication appears to be gained without
effort, whereas for the former human communication “will almost always go astray
unless real energy is expended.”
Moreover, whereas the conduit metaphor has to explain failures in communi-
cation; the toolmakers approach does not see miscommunication or divergent under-
standings as aberrant, on the contrary it assumes such outcomes are the norm.10
This distinction between the conduit metaphor and the toolmakers paradigm is
highly significant for the requirements phase of software development. The terminol-
ogy in current use is heavily slanted towards the conduit metaphor. This indicates that
software developers may be misled into treating communication as a flow between
domain experts, users, and developers; any difficulties or failures then become seen in
terms of blockages or breakdowns in the channelling of information. The basic con-
ceptual imagery of requirements engineering implies, at least initially, that the conduit
metaphor holds true. The information about requirements is passed from ‘users’ to
‘developers’. The requirements exist in disembodied form, and have to be captured.
The toolmakers paradigm on the other hand would draw attention to the difficulties
involved in providing a coherent and consistent view of the system context, an objec-
tive that is inherently difficult and requires collaborative and iterative input from all
participants.
Now every software developer knows that the requirements phase is crucial and
difficult. Obtaining requirements is never done without effort, and software developers
have never deluded themselves that this is easy, or that it is always – or even usually
– done effectively.
A recent issue of IEEE Software [March/April 1998] focused on requirements
engineering. The guest editors’ introduction [Berry and Lawrence 1998] is replete
with mention of methods, tools, applications and so on. This includes mention of
the requirements engineering life cycle. In contrast the general editor himself offered
a view that stressed that ‘the field of requirements (and it no longer matters to me
what word you like to append to requirements to make it sound more esoteric) has
to do with understanding, not documentation’ [Davis 1998, p. 6]. But he pointed out
that it took him over 20 years to shake off the impact of being confronted with a
document entitled “Software Requirements Specification,” a title of three nouns that
took him a little while to decode. It resulted in him viewing requirements as being
10
Reddy offers interesting insights into many commonly accepted views of ‘communication’ and ‘infor-
mation’; including a powerful critique of Shannon and Weaver’s description of their work on commu-
nication and information.
 A. Bryant / Metaphor, myth and mimicry 289

about documenting the external behaviour of a system; something which he now sees
as partial and misleading.
The articles that follow the guest editors’ introduction are all firmly based in
the engineering tradition of software development, and having been presented with
Reddy’s paper, one reads them with an eye for anything that smacks of the conduit
metaphor. The paper by Weidenhaupt et al. [1998], however, begins to transcend this
limitation as it focuses on the use of scenarios in systems development. Although
the project itself has the acronym CREWS (Cooperative Requirements Engineering
with Scenarios), the engineering paradigm is heavily qualified by other features that
echo some of Reddy’s ideas. The descriptions of the many varied uses of scenarios in
actual projects evoke the imagery of the toolmakers paradigm. Thus there is mention of
informal scenarios forming a basis for initial exchanges between developers and domain
experts. Scenarios are seen to be beneficial “when abstract modelling fails,” they help
“enforce interdisciplinary learning,” and “reduce complexity.” In other words, the
usual ‘unblocking solutions’ of methods, tools and so on are insufficient.
The authors couch their findings and conclusions in traditional software engi-
neering terminology; calling for better tools, formal descriptions, management and
traceability. All of these are important, but they fail to take full account of the subtext
of their work; something for which the editor (Davis) has prepared the ground when
he stresses that anyone “involved in requirements needs human skills, communica-
tion skills, understanding skills, feeling skills, listening skills” [Davis 1998, p. 6 –
paraphrasing DeMarco].
The CREWS authors have been drawn away from a critical aspect of their work;
and in part this is a result of their use and acceptance of the engineering metaphor.
This is not to dispute Sommerville’s point about the necessity for some level of rigour
and systematic formality. This is not, however, the complete picture. Such analysis
of the use of scenarios fails to illustrate the aspects of the requirements process that
are brought to attention, if we consider the process at least partially to involve the
toolmakers frame of reference, rather than being restricted to the conduit metaphor.
How much more effective might the requirements process become if viewed in terms
of a dialogue between distinct parties, each with their own assumptions and cognitive
processes; where achievement of mutual understanding is a prime objective, but one
which will not be reached without communicative effort from all participants. Brooks
tells us that changes in metaphor can have real effects on systems; “teams can grow
much more complex entities in four months than they can build.” So perhaps a change
in the metaphor about communication during the requirements process can have a
similar impact.
People are perhaps blinded to crucial aspects of software development because
they are outside the scope of the engineering metaphor. What we need is a collective
jolt similar to the one that Brooks experienced when confronted by the construction
metaphor. But the shift away from the engineering metaphor is rendered difficult
because of pervasive assumptions regarding the nature of engineering and the role of
the engineer.
290 A. Bryant / Metaphor, myth and mimicry

9. Myth

The power and resilience of the engineering metaphor derives from the mythic
status accorded to engineering and the engineer. The term myth in this context is not
to be understood in terms of ‘make believe’, or something that is recognized to be
untrue. On the contrary, as Barthes has argued, myth makes things seem natural and
self-evident.

Myth does not deny things . . . its function is to talk about them; simply, it purifies
them, it makes them innocent, it gives them a natural and eternal justification, it
gives them a clarity which is not that of an explanation but that of a statement of
fact. If I state the fact . . . without explaining it, I am very near to finding that it
is natural and goes without saying: I am reassured. I am passing from history to
nature, myth acts economically: it abolishes the complexity of human acts . . . it
organizes a world which is without contradictions because it is without depth . . .
it establishes a blissful clarity: things appear to mean something by themselves.
[Barthes 1972, p. 143]
This is an accurate characterization of the way in which software developers use
the terms engineering and engineer: They state the fact that software development
ought to strive to become an engineering discipline, but they fail to explain what this
actually involves. It is all too often simply assumed that the audience will understand
what the terms mean, and all will acquiesce with the view that engineering is a viable
and valid objective.
Some engineers and software developers may feel comfortable with this view, but
there is little to substantiate it. Hoare [1975] makes some attempt to describe what is
involved in being an engineer, but the article seems to assume that engineers represent
consummate specialists; embodying the highest ideals of professionalism. The early
work on professionals saw them as imbued with a wide vision, a doctrine of service
to the community, and a high level of autonomy in their activities. Professionals
had some form of certification from their own professional body, and this gave them
independence from commercial and political pressures.
In the 1920s the concept of professionals expanded to include the growing body
of technically-oriented occupations, particularly engineering. Veblen (writing in the
1920s) put forward the idea that engineers were the natural decision-makers in modern
society, since they combined traditional professional values with technological exper-
tise. This was something of an ambivalent view, since it leads to the conclusion
that such professionals, far from being high-minded and independent, become another
component of commercial and political interests. Moreover, many who agreed with
this latter aspect of Veblen’s analysis drew radically different conclusions; thus Merton
argued that far from being natural decision-makers, engineers were in fact imbued with
a “trained incapacity for thinking about and dealing with human affairs” (quoted in
[Johnson 1972, p. 17]).
 A. Bryant / Metaphor, myth and mimicry 291

10. Conclusion

Whether or not people agree with Veblen’s or Merton’s views of engineers, it is

not sufficient to adopt the engineering perspective in an unquestioning manner; partic-
ularly when the ramifications are so important to the bases of software development.
There may well be some aspects of some models of engineering that can provide con-
structive input to software development. Almost certainly this has already proved to be
the case since the engineering metaphor came into widespread use. But it is also cru-
cial to be aware of potentially and actually detrimental effects that such metaphorical
borrowings may have: They may become new historical accidents.
How many times have we heard from ‘real engineers’ that software engineers
are deficient in the real skills of engineering? And how many of these critics would
be able to offer a substantive, let alone definitive, view of what engineering actually
involves? The prototypical engineer is a myth; an influential and important myth, but
nevertheless a myth. We must be careful not to mimic the myth; taking engineering
as something ‘natural,’ but devoid of explanation. We are in danger of accepting
this mythic simplification if we remain unaware of the ways in which many of the
aspects of the engineering metaphor constrain and channel the activities and processes
of software development. Engineering is a complex set of activities, and those who
reject a career in IT, because they (literally) see engineers and scientists as asocial
geeks, are as mistaken as are some of the authors on software development who see
the engineering discipline as the sole model of their discipline. The former are under
the influence of a negative myth, the latter are misled by a positive one; but both
ignore the complexities and contradictions of real-life engineering.
I do not want to suggest that we jettison the software engineering view of software
development. In any case it is doubtful whether such a cognitive transformation would
be possible, let alone acceptable. But it is time that we moved beyond the engineering
metaphor, perhaps taking into account ideas such as those of Brooks, who seems to
wish to lead his readers into consideration of something akin to software horticulture
(which would give a new meaning to the term ‘bug’). Also we have the current
movements based around the metaphors of software architecture and patterns.
We need to be as open to the ramifications of the toolmakers paradigm as we
have been to those of object orientation and the patterns movement. We do not have
to preclude any of the positive aspects of the engineering metaphor, but we do have
to move forward recognizing its constraints and deficiencies. Wittgenstein observed
that metaphor is the way we make sense of things, but it is also the way we produce
nonsense when there is a mismatch between the language that we use and our practices.
We have to avoid nonsense.
Schön offers us a basis for a strategy and a conclusion to the present discussion –
“when we interpret our problem-setting stories so as to bring their generative metaphors
to awareness and reflection, then our diagnoses and prescriptions cease to appear
obvious and we find ourselves involved, instead in critical inquiry” [Schön 1993,
p. 150]. The introduction of the engineering metaphor moved us forward in the critical
292 A. Bryant / Metaphor, myth and mimicry

activity of developing a discipline for software development; we now have to move

this critical activity forward to the next stage.

References

Barthes, R. (1972), Mythologies, Cape, London (French original 1957).

Berman, B. (1989), “The Computer Metaphor: Bureaucratizing the Mind,” Science as Culture 7, 7–42.
Berry, D.M. and B. Lawrence (1998), Guest Editors’ Introduction to Special Issue on ‘Requirements
Engineering,’ IEEE Software 15, 2, 26–29.
Black, M. (1993), “More about Metaphor”, In [Ortony 1993].
Brooks, F.P. (1987), “No Silver Bullet: Essences and Accidents of Software Engineering”, IEEE Computer
20, 4, 10–19.
Bryant, A. (1989), “Better Professionals for the Tools”, In Information Processing 89, Proceedings of
IFIP 1989, G.X. Ritter, Ed., Elsevier/North-Holland, pp. 419–425.
Davis, A. (1998), “The Harmony in Rechoirments,” Editorial in IEEE Software 15, 2, 6–7.
Fowler, H.W. (1965), A Dictionary of Modern English Usage, 2nd edition, revised by E. Gowers, Oxford
Univ. Press, Oxford, UK.
Hoare, C.A.R. (1975), “Software Engineering,” Computer Bulletin, December, 6–7.
Johnson, T. (1972), Professions and Power, Macmillan, Basingstoke, UK.
McDermid, J., Ed. (1991), The Software Engineer’s Reference Book, Butterworth Heinemann, London.
Ortony, A., Ed. (1993), Metaphor and Thought, 2nd edition, Cambridge Univ. Press, Cambridge, UK.
Pfleeger, S. (1998), Software Engineering: Theory and Practice, Prentice-Hall, Englewood Cliffs, NJ.
Pressman, R. (1992), Software Engineering: A Practitioner’s Approach, 3rd edition, McGraw Hill,
London.
Reddy, M.J. (1993), “The conduit metaphor: A case of frame conflict in our language about language,”
In [Ortony 1993].
Schön, D. (1993), “Generative Metaphor: A perspective on problem setting in social policy,” In [Ortony
1993].
Sommerville, I. (1996), Software Engineering, 5th edition, Addison-Wesley, London.
Wasserman, A. (1996), “Toward a Discipline of Software Engineering,” IEEE Software 13, 6, 23–31.
Weidenhaupt, K., K. Pohl, M. Jarke, and P. Haumer (1998), “Scenarios in Systems Development: Current
Practice,” IEEE Software 15, 2, 34–45.
Weizenbaum, J. (1984), Computer Power and Human Reason, Penguin, Harmondsworth, UK.