Episode 149: Difference between Software Engineering and Computer Science with Chuck Connell

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.)

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.