Software Engineering - A Valid Aspiration?

I was listening to an interview with Alistair Cockburn tonight on my way home and thought he had some interesting insights into the subject of whether we should aspire to the concept of "Software Engineering."  He had three basic points which I'll relate:

First, engineering as it is conceived today, is a rather new invention.  Before 1950 or so, engineering was less math-intensive and more exploratory.  It was about invention over theory.  As Alistair puts in, after World War 2, engineering got "physics envy" and began to move heavily into theory and math.  This isn't necessarily bad (although there are definite side effects to it), but aspiring to be an engineering trade doesn't necessarily mean the heavy-theory, plan everything in advance model we seem to accept it as meaning.

Second, the term "Software Engineering" doesn't have the origin you probably think it does.  My thought when I hear this is that someone looked at software development and said, "you know, this looks a lot like engineering."  In fact, that's not what happened.  In 1968 there was a NATO conference on software development and, in order to be "deliberately provocative", they decided to use the term "Software Engineering" to describe the industry.  This was done more to force the industry in a particular direction than to reflect where it really was.

His third point is that software development is not really engineering--especially our modern view of that term.  It is rather like a cooperative game.  It is exploratory in nature.  The actions taken are two:  invention and communication.  He expands on this idea in his book, "Agile Software Development."  The advantage of thinking of it as a game is that we can see that there are not right and wrong moves but rather better and poorer moves.  You don't win a game by following a ridgid formula.  Instead, you react to the circumstances.  You need a strategic plan, but you also must remain tactical.  A good place where this becomes useful is in the concept of documentation.  It isn't that documentation is intrinsically good (ISO 9001) or bad (XP), but rather we can decide for each project how much documentation is appropriate.  Weigh the costs and the benefits and decide what to do.

Alistair has some good points here.  Similar to my post about why building software isn't like building bridges, he focuses on the naturally exploratory nature of what we do in software.  It is more about making tradeoffs and reacting to the state of the game than about making a priori decisions which will be applied to the situation in a rigid manner.

 

Part of this interview is typed up on this blog.  The official transcript seems to be here.