Metaphor, myth and mimicry: The bases of software engineering

• Authors: Antony Bryant
• Venue: Annals of Software Engineering
• Year: 2000

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*. *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.’