“Metaphor, myth and mimicry: The bases of software engineering”
For most of the first half of article author discusses “software engineering” metaphor, and whether some of the concepts from engineering field have sense in software development discipline. Author states that language used has impact. Metaphors come with some linguistic baggage but can lead to perceiving things differently which itself can advance theory and practices of software development.
In my opinion it does not matter whether someone disapproves calling software developers engineers. That word indeed comes with a lot of baggage. I am an engineer and if I say only that then people might think that I know how to make a shed. They get back on track when I add that I am software engineer. Obviously some things have changed in perception of software engineers since author published article, but even still the word ‘engineer’ alone comes with connotations. In the end it does not matter, all that matters is working software. In order to get to that point one has to face problem of software requirements which is being discussed in second half of the article.
At this point it is worth noting article was published more than decade ago which in this area seems more like a century. At the very beginning Bryant uses expression “requirements phase” and after that discusses multiple nouns that can be added before or after word “requirements”. I am more interested in the word phase. Nowadays it is obsolete to talk about phase. From my experience requirements are being gathered and changed during whole development process. It is hard to talk about any time-boxed phase. Let’s keep that in mind and go on further with analysis.
Bryant brings up two communication schemes presented by Reddy. One called toolmakers paradigm and the other conduit metaphor. Bryant says that “The terminology in current use is heavily slanted towards the conduit metaphor”. Then he says
“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” and follows with “perhaps a change in the metaphor about communication during the requirements process can have a similar impact.”
I think that a lot changed in that matter. I would say that both parties understand the problem of communication and requirements. Nowadays it is more like “toolmakers paradigm”. There are movements like DDD which put special emphasis on understanding domain of the problem. It comes with new terminology like “knowledge crunching” which might be more suitable to toolmakers paradigm. However even though DDD is well known it is not very well understood by majority of developers. Moving to other example, agile methodologies help with requirements in a way similar to showing blueprints like in toolmaker’s story, but here blueprint is a working software according to some requirements which will change. Change of requirements is anticipated from the start. If the communication was wrong, if there were misunderstandings then it is nothing unexpected. It is the norm. Requirements change along with deeper understanding of domain by developers as well as clearer vision of what client really wants. However it is not always the case that agile methodology is used because it requires client to actively participate. These clients have mindset focused on “achieving mutual understanding” because this is what is most economically reasonable. What about others? Some of them live in world where communication is done only in one direction and only through written documents. In conclusion it is getting better but there is still a long distance to go.
Bryant says:
“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.”
Once again, for me it’s just a fancy word which labels me as technical person and professional. Sometimes software developments seems like an art which has very little with engineering. I do not feel any constraints implied by that word. The best I can do is to just improve my skills which help with getting my job done. It does not matter if these are technical skills or not.
“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.” “The introduction of the engineering metaphor moved us forward in the critical activity of developing a discipline for software development; we now have to move this critical activity forward to the next stage.”
I agree and I think that we have already moved beyond that metaphor to something more substantial than engineer.
In summary I think we moved to that point where developers are pragmatic enough to not care about labels pinned to them. If I had to choose the current metaphor I would say that “Software craftsmanship” is the most adequate. Maybe that’s the next stage Bryant wrote about.