... of saying of Parnas: "Most students who are studying computer science really want to study software engineering but they don't have that choice." (http://www.sigsoft.org/SEN/parnas.html). While I generally agree with Chuck Conoll, I think the relationship between software engineering and computer science is more complex. Okay, the separating line is there but sometimes you jump to the other side because it becomes necessary. As for example Edgar Codd did: He did work on database systems and saw all the messy programs and decided to create a mathematically sound theory about databases which is still valid today. Nobody can ignore the huge success of relational databases and if today a software engineer rejects to use a relational database for dealing with a large amount of structured data he has to give a very very good reason for doing so!
Science in my opinion is not about what but more about how you do someting: do you use scientific methods? The example of Chuck is illuminating: He says you cannot estimate how long a project will take because half of the team could get sick. But even in this situation I can use scientific methods to estimate what the probability for this case is. I can use data from history or use data from other employees to have a more or less accurate estimate. Of course it must be a statistically sound analysis as is described in statistic books. But if you just say: Well, we cannot know, anything can happen, I feel it will last 2 months to finish.. you see the difference?

"Software Engineering" and "Computer Science" are fat words indeed. They are fat words because we still have difficulties to define our identity as a discipline. Framing practical software development as engineering would mean that we act like engineers - having generally accepted rules of the profession, using standards, models and scientific methods where appropriate, refrain from reinventing the wheel and taking into account such things as quality, management techniques, economics. As long as we reduce software development to code writing and some second class helping tasks, hoping that the solution of our user's problems will magically emerge from thinking about code, we will not be able to figure out what the meaning of software as an engineering discipline is. I am afraid that the old time of software developers as high-priests of the machine are still lurking around the corner. And possibly, software craftsmanship is a better metaphor than software engineering to describe our profession.

To my opinion, computer science still has difficulties to understand its possible contributions to software practice. A software engineering discipline would need to use knowledge from different scientific disciplines such as mathematics, psychology (for the UI staff), economics, management science and also computer science. However, scientific knowledge must be customized and packaged in order to be useful to engineering disciplines. In other engineering disciplines, this has been the result of a long and still ongoing process of communication and learning. That process has not yet started in the domain of software, because software engineers dislike computer science (NIH) and computer scientists approach theit relationship to practitioners from a wrong angle. Computer scientists still believe they have superior (formal) methods and tools ready to be pushed down into practice and don't understand the need to market, sell and adapt their results based on their usefulness for practitioners.

Erich Pawlik

I really like the episode - this has always been a hot topic amongst me and my peers - whether Computer Science and Software Engineering are two terms for the same thing or completely different things. The topic is always controversial and when you throw in the movement around software craftsmanship can be potentially explosive :-)

I have written a short review about the SE Radio podcast here - check it out...

Keep up the good work !