What is software engineering?

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.

3 thoughts on “What is software engineering?

  • November 17, 2014 at 11:22 am

    I think your approach is the right one. I also would appreciate a chapter or an appendix on agile methods and their limitations, when and why to use them into software development. The risk is that you write something that some students are not interested about. But if you want to make your book up-to-date and complete you should have to write more about agile methods and software product development, even using your enthusiast’s perspective. I would appreciate the reading for sure. But this is just a student’s point of view.

    • November 17, 2014 at 1:22 pm

      There’s a chapter on agile methods in my current book but a forthcoming new edition will have more.

  • November 19, 2014 at 5:45 pm

    As I see it software engineering comes down to three questions:
    – What am I creating?
    – How do I know I am done?
    – How do I accommodate for change?

    — What am I creating —
    I agree that agile methods are not the silver bullet of software engineering. In my experience new projects often originate from an idea. Whether a non-software professional or a software profession is the origin of the idea is not that important. We often do not know what we want up front for some problems. Most people, including software professional programming a project, often don’t have every facet of the code worked out before we begin. An agile approach does give you a starting point. After so many iterations the exact requirements of the software will become evident at which you can begin to design from that perspective.

    — How do I know I am done? —
    Once you have a requirements you can begin to develop tests that enable you to discover an ambiguity in them. You cannot test ambiguity. Well at least not thoroughly enough to banish the specter of uncertainty when answering the question of whether you are done. Once any ambiguity has been removed a set of tests can be conducted, best by people who haven’t programmed the system to remove any bias, to enable the customer to see if the software meets all your needs. I consider this part similar to someone walking through a newly built house. You have the plans and what is supposed to be done in each room of the house. If there is no bathroom and they plans call for two then you know the house does not meet the requirement. Currently I see little in literature that talks about using testing from this point of view. Most people still view software design as I tell some technical people to make something then I try to use it. We need more discipline than that.

    — How do I accommodate for change? —
    Very few projects are a once and done kind of work. Student homework is an exception. In my experience once you have a working solution the day comes when someone says “It would be nice if the software did ….”. Good software engineering embraces change. Change is all around us. So a good software engineer has the skills necessary to be able to refactor old designs to improve the clarity of the code. Easier to read code is easier to optimize. Code bloat and other artifacts creep into it as it ages. If we don’t spend time to remove them periodically it may be too late or too expensive to change them. When we do make the changes we always have to consider the second question to know when we are done. The changes cannot break anything in the past. If we have a good test suite we can be assured, with reasonable certainty, that when it passes the code meets the new need and we are done.

    I am sure there are probably more attributes to what is software engineering. These are the ones that I see come up as I work as a software engineer in various settings. I need to keep abreast on the advances in this field as well as being a generalist in many because software is being created for all sorts of problem domains.

    Well these are my thoughts for today.

    Stephen Torri, PhD (Lancaster class 2001)


Leave a Reply to admin Cancel reply

Your email address will not be published. Required fields are marked *