|

It’s engineering Jim

Posted on Tuesday, 02 October 2007 at 21:12.

What follows is a review of It’s Engineering Jim … but not as we know it, a paper by prof. Anthony Bryant. The review was written on 21 September 2007 for my software engineering course, taught by Jurriaan Hage.

Abstract

This review is part of the Software Engineering course for the Software Technology master programme at Utrecht University. The article reviewed is “It’s Engineering Jim … but not as we know it”, written by prof. Anthony Bryant from the Leeds Metropolitan University. First I will summarise the paper. Then I will describe the position of the article in the field of software engineering. Thirdly, I will answer the question included in the assignment. Finally, I will tell you what I personally think of the paper.

Summary

Bryant begins by explaining that nobody really knows what is meant by the term “software engineering”, or that a consensus was only reached after long discussions, and that even then only the group of people that came up with the definition truly understood what they meant. According to Sommerville, software engineering is usually understood to mean that the development of software should be practised using theories, methods and tools from or based on other engineering disciplines. Its practice should be structural and have a “rigourous basis”. Bryant argues that this raises expectations of software developers that usually cannot be met in practice: the software crisis he mentions in his article’s subtitle.

He mentions that Sommerville also explains that software is essentially and crucially different from the other engineering disciplines in that software is immaterial: a warning that “engineering” might not be a very appropriate metaphor for the development of software. The idea that “we cannot build scale models” is one that struck me in particular, and is an excellent example of the intangibility of software. But humans like metaphors: they help them understand and analyse things, especially software development, since it’s so (relatively) new and complicated.

Bryant continues by explaining how influential metaphors are, and that they “play an active role in thought and cognition”, steering thoughts and understanding in certain directions. The metaphor “projects upon the primary subject [i.e. software engineering] a set of associated implications”. In this particular case the “waterfall model” of designing first and then implementing is directly taken from engineering, while an incremental model might be better in certain cases. He describes how Brooks noticed in his paper No Silver Bullet that “software development [is] more akin to growth than construction”. Bryant mentions this idea of growth several times more, for example when he quotes Brooks again, saying “teams can grow much more complex entities in four months than they can build.”

And this is where the danger lies: while metaphors can help in understanding concepts, they can also hamper the understanding. The metaphors don’t only guide towards certain points of view; they also guide away from others. Metaphors are so powerful that they continue to influence us adversely even when we are aware of their limitations. As an example, Bryant explains the influence of the conduit metaphor (introduced by Reddy) on the determination of requirements, an early step in the development of software which is often seen as important and complicated. The conduit metaphor is the idea that information is transferred from one person to another. The parties involved in the determination of the requirements aim to explain their ideas to each other, but instead they should have mutual understanding as prime objective, where the explanation is a tool instead of the goal.

Bryant says that the process of using one metaphor, then shifting to another one is a natural process in science, and a necessary one for progress. He suggests that while the software engineering has been useful, it’s lost its importance and should make way for a newer paradigm. While he doesn’t explicitly suggest software architecture should become the new paradigm, I feel he does hint at it as an interesting possibility when he mentions Sharp and his idea that “architects are trained differently from engineers.”

Position within the field of software engineering

The article questions the very roots of the term “software engineering” and therefore of the whole software engineering field, discussing the problems associated with the term, arguing that metaphors have a very strong influence on the practice of software development and science in general, and finally suggesting that the metaphor be replaced with a newer one, giving a new impulse to the practice of software development.

Answer to the question

The question is:

Does Bryant argue that software engineering is superfluous?

My dictionary defines superfluous as unnecessary, especially through being more than enough. Therefore, I think the answer is both yes and no: no, software engineering has been far from unnecessary. It was a natural, necessary and useful step in the development of the science of computing, of experience with creating software, and of insights into the field. Bryant merely argues that the term software engineering has reached the end of its usefulness, since at its current state it hampers software development more than it helps it. In that sense, yes, software engineering has become “more than enough”, but only after having served its purpose for several years.

My opinion

I found the paper interesting to read, although at times it was hard to understand. Bryant sometimes writes his sentences in such a way that they require reading at least twice for me to understand them. I also think he could be less verbose: I got the feeling that he was making the same point several times in his article. Nevertheless I think his point is a good and interesting one, and it made me realise that metaphors and paradigms indeed have a huge influence on our progress of understanding, not only of software development, but of everything we research.

Leave a comment!

Martijn loves to receive comments! Add yours by filling out the fields below.