I wrote the 1st edition of my book on software engineering at the beginning of the 1980s when there was no doubt what software engineering was about. The ideas underlying software engineering then came from military and aerospace systems. Large business systems were built using the same approach so there was no ambiguity about what software engineering meant.
Conversations that I had earlier this month showed how much things have changed.
One was with an old friend who works for a company developing safety-critical software for air traffic management. We talked about how I was updating my book and I said I was revising the chapter on agile methods. His response was that he had never really paid much attention to agile methods. This is not at all surprising because, the fundamental approach to safety-critical system engineering is still recognisably the same as the development methods used in the 1980s. This type of system needs the detailed analysis of specifications and design that is fundamental to these methods.
The other conversation, a week later, was with one of my successful PhD students who has recently been appointed to a senior engineering job at Rightscale, who develop software products for cloud management. We talked about software to support teams working across continents and continuous integration tools to support daily product releases. Again, for this type of software system, the agile, rapid development approach to software engineering that Rightscale use is absolutely the right one for the type of software that they develop.
For those of us who write about and who are involved in teaching software engineering, this presents us with a problem. What do we say? The agile approach to product development is so far away from the detailed, analytic approach to safety critical systems engineering that I don’t believe there is a useful unifying abstraction that links them.
Software engineering now is so diverse that it is impossible to cover all approaches in a single book or series of lectures. My approach has been to focus on the development of custom software rather than domain-specific or consumer software products. For custom software, we still need some kind of requirements statement to define what has to be implemented for the customer but a mixture of agile and traditional plan-based techniques may be used. I adopt this approach partly because I think it is important to demonstrate that agile is not the answer to everything and partly because it’s what I know and I think it’s always better to write from experience.
But I wonder if this is the right one? Should I write more about agile methods, software product development and software process automation? I am an enthusiast for agile methods and incremental development but these methods have serious limitations that people have to know about. Is it better to discuss these limitations from an enthusiast’s perspective or using my current approach?
From a teaching perspective, I don’t think it makes sense to think about software engineering as an ‘add on’ to computer science courses as is often the case. If we are to cover the diversity in the discipline, then this can only be done within the framework of a dedicated course that introduces all approaches to software development. I’ll write about what I think should be in a software engineering degree in another blog post.