Hexacta Blog

Last month I had the chance to go back to Carnegie Mellon, the place where I studied 17 years ago. It was a great experience to see how the place has changed and to meet again good old friends. I was given the chance to give an alum presentation that I decided to title “On the cruelty of really applying what you learn in the MSE (Masters of Software Engineering)”. The title was inspired on Dijkstra’s manuscript “On the cruelty of really teaching computer science”, which is very, very interesting, because it describes how sometimes we fail to recognize some things that are radical novelties as such. The problem in these cases, according to Dijkstra, is that we try to link the radical novelty to what we already know, the new to the old, and, according to him, these attempts are doomed, because what we know is “hopelessly inadequate”. I used this title because applying what I learned in that program is also cruel in some ways. First, because what you learn there is fundamental, so some things can’t be applied directly, second, because some things are novel, so they can’t be applied immediately, and third, because our field is too wide, so some things might not be useful to all students.
But there’s also the cruelty of trying to be a software engineer. Many say that software development is not an engineering discipline because it’s not mature enough. Dijkstra used to say that it’s a doomed discipline because it’s an attempt to apply something familiar (engineering) to a radical novelty. Others say that developing software is more an art than an engineering discipline. And traditional engineers, when you explain them that physics and chemistry are of little relevance for developing software say “if it doesn’t require physics or chemistry, then it’s not engineering”.
But let me get to Dijkstra’s argument, which is very interesting. How many times did we make mistakes in the past by trying to apply practices from other engineering disciplines that were not adequate for software? Is that the case of many things we tried to copy from manufacturing? Is that the root cause of the “waterfall mentality” that still persists in many places? I think that saying “All previous engineering knowledge is useless for developing software” is clearly wrong. But we should also be more careful when we try to use things from other disciplines. And this applies not only to people like me that want to inspire in traditional engineering, but also to people that claim that software is an art (I’m talking here about developing large software systems, not the “art of programming” that Knuth described so well).