In early 2008 I came across two views put forth in the SEN November 2003 issue on the distinction between Software Engineering (SE) and Computer Science (CS). I originally held one view, but now I have come to think that the other is, if not more correct, at least more useful for the advancement of SE as a profession. To help me understand why I changed my view, I wrote a rather long essay (available from my home page). This is a distillation of one of my main points - I have been involved in both CS and SE programmes, and my change in view is due to my experience in these two worlds.
The two views were put forth by a letter to SEN by Bill Griswold, and a response by Peter Henderson in the SEEd column. Bill's view (which was a response to a proposal for an SE curriculum), was that CS is Engineering, based on the observation that much of what is associated with CS involves the construction of artifacts. He felt that SE was a sub-discipline of CS, and questioned whether making any distinction was of benefit for the development of the respective fields, in research and in teaching.
The other view was by Peter Henderson, presented in his SEEd column in response to Bill's letter. Peter felt that there was a difference between CS and SE just as there is a difference between science and engineering. He felt that many graduates of CS programs don't have an "engineering mindset", and did not think that most CS programmes produced this mindset.
I spent 11 years teaching in a fairly standard CS programme, where SE was a part of CS and I had no reason to think otherwise. I had seen discussions relating Software Engineering to engineering, thought I understood what they meant - and still thought SE was part of CS, that is, I agreed wholeheartedly with Bill.
In 2002 I changed institutions and began teaching into an SE programme that was part of Bachelor of Engineering (BE) degree. The BE is run by a School of Engineering, which has been around a long time (now just over 100 years). The SE specialisation had provisional accreditation by the national engineering professional body at the time I started, and so had been designed both with Washington Accord requirements in mind, and to fit into the existing BE structure. That structure included a common first year consisting of courses developed for the traditional engineering specialisations, with nothing relating to SE (unless you count a half-course on MATLAB). I was unimpressed with this situation as it seemed that SE students were having to spend a lot of time on irrelevant material.
The justification given to me for why all first-year engineers had to take a common first year was, in part, to give all first-years a flavour of the different specialisations, but I was also told it was to begin the process of developing this "engineering mindset". I didn't buy it. I figured it was just the old traditional engineers guarding their turf from the johnny-come-lately SE, which wasn't even true engineering anyway (with apologies to my Engineering colleagues!)
Then in 2003 the first cohort of SE students graduated. These graduates were largely taught by members of the Computer Science Department in the Faculty of Science (that is, not the School of Engineering), who were (like me) mainly from the standard Computer Science tradition. However I saw a distinct difference in these graduates to what I had seen of Computer Science graduates. It's difficult to quantify, but it wasn't just that their systems were of good quality, it was that their view of quality was different, I think considering more what the client wants rather than what they considered to be good.
What I saw in the first cohort I have seen in all graduating years since. It is possible that the difference is due to the higher entry requirements to the SE programme than the CS programme, however I do not believe that the average quality of the students is different between the two programmes - the top CS students are generally better than the top SE students, and I would consider them a match for the top students from CS programmes around the world. Nor is the CS programme significantly different in nature from other CS programmes I have seen around the world.
The SE students do seem to have a different mindset. I assume it is this engineering mindset everyone is talking about, and I have to say, I like what I see. As it has been much the same people teaching the SE programme as the CS programme, I have to conclude that it's the structure and environment of the engineering programme that's made the difference.
The CS programmes I've seen produce valuable graduates, and so I am loath to change all such programmes to produce the same kind of graduates that come out of our SE programme. We need both kinds of graduates, but I feel that currently there is confusion in academia, the research community, in industry, and the general public as to what the distinction is between the two kinds of programmes. If anyone were asked what a lawyer, accountant, doctor, engineer, or architect is, they would have a fairly good idea. This would be also true of sub-professions - a chemical engineer versus an electrical engineer, or a surgeon versus a general practitioner. But ask what a "software engineer" is of 10 people and there is likely to be 10 (or more) different answers. This can't be good for SE as a true profession.
Of course it's easy to say that there is a difference, but unless we can come to some general agreement as to what the difference is, the confusion will continue to exist. I am not saying we should create some artificial divide, but that we develop a small set (e.g. of size 1) of criteria that can be used to decide such things as which world a programme belongs to. I look forward to the debate!