Software Engineering Radio

I appreciate Chuck’s interest in speaking about Software Engineering as well as his opinion on what direction Software Engineering should probably head towards.
However, I completely disagree with the central message of the talk – that Software Engineering cannot ever reach a level of mathematical predictability. First, there’s a reason why it’s called software **Engineering** – engineering inherently is not science. Engineering, as a discipline involves analyzing trade-offs, decision making and **attempting** to come up with the most optimal solution given the environment, resources and goals involved.

I am fairly sure that no SE professional or researcher has ever claimed that software engineering can be made “mathematically” provable like classical computer science. So, the entire argument against software engineering in general and clean room engineering or formal methods in particular is based on inaccurate assumptions.

The speaker seems to have misunderstood the “math” in software engineering. The math in software engineering is not aimed to be theoretical math at all. Just because the speaker’s assumptions made him believe otherwise doesn’t mean that the metrics and models involved are “fake”.

The next thing I disagree with is how the speaker represented Software Engineering as being merely “Process Engineering”, while completely ignoring Architecture, Modeling, Quality Assurance and various other key sub-disciplines.

Yet another thing that made me cringe is when the speaker compared Software Engineering to Civil Engineering and claimed that building constructions and such are usually on schedule whereas software is almost always late. Implying that Software Engineering is somehow to blame for poor estimates and practices is a logical fallacy, much like blaming the field of medicine for people’s poor health. It’s not Software Engineering but a *LACK OF* Software Engineering that is to blame. Maybe we should have fewer CS majors and more Software Engineers on projects.

Now about formal methods. I’m still amused at how the speaker managed to bash formal methods without having apparently dabbled much with it. To anyone that’s not familiar with formal methods and tools such as Alloy modelling tool or Prolog, here’s an example. Suppose you need to design a social networking site and the requirements state that you should be able to add friends, remove friends and be able to see friends of friends. Even with this very simple model, there could be umpteen scenarios and there’s always a chance that while programming the solution, you miss out the case where “blah blah blah happens”. The more complex your business logic, the more likely there are to be scenarios that you hadn’t anticipated and don’t know how to handle. With a tool like Alloy, you could essentially define your business logic as is presented to you and the **tool itself generates all possible scenarios and implications** of your defined business logic. After which, you could have your Asserts to ensure that the generated scenarios do not violate your business logic.

Alternatively, you could define the rules for a sudoku game and have it generate “all possible solutions”, and presto you have a sudoku solver

Why the speaker felt compelled to compare it to automaton theory or why he found it “mathematically” unsound is still beyond me. For the umpteenth time SE is *engineering!!* and not science.

Overall, it was somewhat sad to note that the speaker was only familiar with the buzzwords of Software Engineering and that his opinions were quite un-informed.

PS: Incidentally, my university has a dedicated Software Engineering department that is *completely separate from the CS department*, and I’m fortunate to be part of such a rare breed of undergraduate programs.

Thanks SE radio for the interview – maybe we should have a real Software Engineer or researcher on the show.. oh wait.. most people on here ARE real Software Engineers – Kent Beck, Erich Gamma, Grady Booch, and most talks ARE about Software Engineering, oh and that’s why it’s called Software Engineering Radio!…( Markus should have peppered him with stronger arguments! haha.. just kidding.)

@doudo & @Erich: +1

Completely agree with the fact that you need more than just CS to take concepts from the research lab to the industry. Usability, economics, performance, quality,… there is obviously a lot more involved in making a successful software product than amazing algorithms. I like to use the analogy of chemist/pharmacist and doctor, where even the most ground breaking drug can be useless(or fatal) without proper diagnosis, dosage, etc.

@kjmcsd: “It is sad but you will be hard pressed today to find any school anywhere that has a software engineering program.”

Ever heard of SEI at CMU?

A great discussion! Probably one of my top 10 favorite se-radio episodes. I’m not sure that I agree with the concept that human interaction is what drives the difference between software engineering and computer science. But, that idea is an interesting framework for other discussions, especially about programming language design. For example, after hearing this episode, there’s a bunch of questions I wish had been asked in earlier se-radio episodes of Guy Steele and other programming language designers:

If the object of programming language design is to make it easier for humans to write correct, efficient programs, how do we test the design to show that any particular language feature does just that? There are UI testability labs (perhaps another interesting SE-Radio topic?), can we do the same for programming languages? If we aren’t testing and measuring the impact of design decisions empirically, we aren’t engineers, much less computer scientists.

“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 !

… 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?

It seems like “computer science”, “software engineering” are fat words. A fat word is a word like “freedom” that has so many associations and means so many different things to different people that it effectively has no meaning at all. Two people can discuss freedom for an hour an not communicate at all. The fact that a university has a department called “computer science” tells you very little about the research interests of the faculty.

These words are also related to the image which “computer people” want to project. The term “computer science” is an attempt to put the study of compter programming on a par with physics. Computer scientists will develop grand mathematical theories that will describe all of nature (programming). “Software engineer” is another similar term. I am an embedded systems programmer and have always worked on projects with other disciplines like electrical and mechanical engineering, It is very important to be called an “engineer” so that you can have equal status. God forbid that anybody should call you a “programmer”. I have a masters degree in electircal engineering and still have difficulty getting mechanical and electircal engineers to view me an “engineer”. “Software developer” is yet another similar term. People who use it have ackowledged that they are not an engineer but are uncomfortable with “programmer” label.

There is a major difference between software engineering and computer science! The person was correct when they said that students major in computer science that want to major in software engineering. I was one of them! I received my Math/CS undergrad degree and then I ended up searching for months for a graduate school which offered software engineering until I found UMUC. I attended UMUC for 7 years and then they changed the software engineering program to information technology because they said they were doing it to keep up with the times. I totally disagreed and decided not to switch my degree to IT. I graduated with a degree in software engineering.

The difference between computer science and software engineering is huge. In my own words, Software engineering is the study of how to create quality software where as computer science is the study of computer architecture and algorithms.

It is sad but you will be hard pressed today to find any school anywhere that has a software engineering program.