Douglas Hofstadter believes that analogy lies at the core of all cognition. Even if you don’t subscribe to this unorthodox opinion, it is hard to argue against the value of a good analogy when getting to grips with a new subject. The danger, of course, is in overextending the analogy; conversely, the key to its effective use is knowing when to stop.
Is the term “Software Engineering” an analogy that has been overextended? It was originally coined by the organisers of the NATO Software Engineering Conferences:
In the fall of 1968 and again the in fall of 1969, NATO hosted a conference devoted to the subject of software engineering. Although the term was not in general use at that time, its adoption for the titles of these conferences was deliberately provocative. As a result, the conferences played a major role in gaining general acceptance, perhaps even premature, for the term.
It is worth reading the thoughts of Brian Randell, who was one of the editors of the proceedings of the two conferences. For me, the key statement is:
Unlike the first conference, at which it was fully accepted that the term software engineering expressed a need rather than a reality, in Rome there was already a slight tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an International Software Engineering Institute. However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive support for this proposal were instead marked by considerable scepticism, and led one of the participants, Tom Simpson of IBM, to write a splendid short satire on “Masterpiece Engineering“.
And so the bandwagon started rolling. I think it was reasonable to adopt the term “Software Engineering” to indicate that producing large software systems is analogous to established engineering disciplines in terms of some of the disciplines required in order to be successful. However, that does not imply that it is similar to more traditional engineering disciplines in all ways: in particular, it does not imply that the “design then build” construction analogy is valid.
This was best explained by Jack Reeves in three articles on Code as Design. I think these articles should be mandatory reading for anyone involved in software development projects, so please take the time to read them for yourself. His key point is that:
The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design.
Almost 20 years ago he had great insights into the nature of software development, and yet our industry still hasn’t fully grasped the implications. Design is an inherently creative, unpredictable process; construction is an inherently rote (though often very skillful), predictable process. They require different kinds of people and different approaches to project delivery.
It is too late to consign the term “Software Engineering” to the history books, but we need to be aware of the limitations of the analogy. So, if we accept Jack Reeves’ premise, what should we be doing differently?