Archive for April, 2010

Is decision making a key skill for software engineers?

Friday, April 16th, 2010

A few weeks ago I attended the 23rd annual software engineering education and training conference in Pittsburgh. One of the keynotes was given by Alistair Cockburn, one of the authors of the Agile Manifesto. His lecture was titled “Teaching the next generation software engineering”, and the slides he used can be found here: http://alistair.cockburn.us/Teaching+the+next+generation+software+engineering.pps. In his lecture, Mr. Cockburn explained that people can learn skills in three stages, following a Japanese martial arts concept: Shu – Learn one technique, Ha – collect techniques, and Ri – Invent / Blend techniques. Mary Shaw, who always has good questions that are hard to answer, was in the audience and seemed very interested in the subject. This time her hard question was: “How do you teach students how to choose between different techniques?”

I often say that the best software engineer is the one who knows many different tools, techniques, methods, and has the skills and judgment to choose among them. Now… the question is: how do you do that? This is like going to a restaurant. On a plane, the dinner decision “chicken or pasta” only takes a few seconds. In some Argentine restaurants the menus are up to 10 pages long, and it takes forever to make up your mind. Of course there are several standard decision making techniques that we can use as software engineers. But I’ve never seen that as a focus of our education or the skills that we need in our job. Maybe it’s time to review that. Also, we might need specialized decision making techniques. For example, the SEI has done a nice job by linking quality attributes to architectural decisions. We need more of that for other key decisions we have to make when we develop software, both for managerial and technical issues.

On the cruelty of trying to be a software engineer

Thursday, April 8th, 2010

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