ICSE 2012 Roundup

Several folks have asked me what I thought of ICSE 2012. Here's what.

Full disclosure: ICSE 2012 was sponsored in part by Zuhlke Engineering AG, a sister company of my employer Zuhlke Engineering Ltd, and on that basis I was an “invited industrial speaker” at the conference. However, what I write here are purely my own opinions and do not necessarily represent the opinions or policies of any of the Zuhlke Group companies.

Phew. Well, am I glad I went? Yes. Would I go again? Not in a hurry. Next year is San Francisco—not interested. 2014 is Hyderabad—very interested!

To begin at the end, at the closing plenary Lionel Briand was awarded the IEEE Computer Society's Harlan D. Mills award. In his address he appealed for software engineering research to come out of the shadow of computer science and function as a stand-alone discipline. This crystallised a thought I had half-formed during the conference which was that many of the papers presented did seem a bit like second–rate computer science. And that's not right. Software engineering should no more be cheap'n'cheerful CS than mechanical engineering should be bargain basement physics.



It seems to me that the difference between pure science and applied science is that applied science has to be useful as well as interesting, and the difference between engineering and applied science is that engineering has to make money. A solution is good engineering if it solves the problem at hand and makes a profit. Various people are credited with saying something like
an engineer is someone who can do for $STEREOTYPICAL_SMALL_SUM _OF_MONEY what any fool can do for $STEREOTYPICAL_LARGE_SUM_OF_MONEY. 
So, let's look at the programme of ICSE 2012[pdf] and search for “econmic”. There are 4 hits, all in two of the keynotes. Either Saskia Sassen's talk on Digital Formations for the Powerful and Powerless (which was met with derision, so far as the conference twitter feed suggests) and Frank–Dieter Clesle's talk on Supporting Sustainability with Software. No papers. Not one.

Here is a word cloud prepared by Adrian Kuhn of the words that are in the papers at ICSE. To me, the big words look very closed, very inward–facing, rather self–centred.

Contrast this with the programme at the ASME 2011 International Mechanical Engineering Congress (at the time of writing the 2012 programme was still being worked out). Here are some sessions titles:
  • An Integrated Energy, Carbon, and Economic Analysis of Reclaimed Water Use in Austin, Texas
  • Economic Feasibility of Nuclear Desalination for Abu Dhabi
  • Technoeconomic Analysis of Biomass Gasification System Utilizing Geothermal Steam for Processing
  • Energetic and Economic Performance of a Compressed Air Energy Storage Facility in Texas as a Function of Technical and Cost Parameters
  • A System Performance and Economic Analysis of IGCC with Supercritical Steam Bottom Cycle Supplied with Varying Amounts of Coal and Biomass Feedstock 
And so on. This year's American Institute of Chemical Engineers annual meeting has “economic” in the very strapline, and pages of hits for session abstracts that mention economic issues. Compared to these the ICSE program, for all the good intentions and hard work that have gone in to the material, looks a bit...immature, a bit amateurish.


Papers I Liked

Laura Plonka, Helen Sharp and Janet van der Linden examined Disengagement in Pair Programming. Does it matter? Answer: often yes. They show why your pair can tune out, why that's a problem, and offer some techniques for dealing for it.

Felienne Hermans, Martin Pinzger, and Arie van Deursen built tools for Detecting and Visualising Inter-worksheet Smells in Spreadsheets (slides here). Hermans was one of the stars of the conference, as this word cloud of tweets about the conference shows. And rightly so. This paper alone is a lovely piece of work. It takes ideas from the world of programmers' programming and applies them to the much wider, and very important, world of end–user, reactive, data–flow oriented programming known as “spreadsheets”.

David Budgen and Sarah Drummond ask What Scope is There for Adopting Evidence–Informed Teaching in SE? One would hope, quite a lot. This is part of the effort to promote Evidence Based Software Engineering, the rather radical notion that perhaps software engineers should do what works, because they know it works. The paper provides a survey of SE research literature that might be used to teach students what's known to work.


And the opposite of that

Conversely, the SEMAT panel proudly announced that while the SEMAT kernel has yet neither been (1) completed nor (2) tested in industry, it is already being taught to students. This would seem to be the opposite of evidence–informed teaching. Speculation–informed, perhaps. This is enormously disappointing, as is SEMAT.

While SEMAT is advertised as something like an attempt to reboot (in the “Spiderman” sense) the whole discipline of software engineering (such as it is), it seems to have ended up as an exercise in flogging the same old dead horse. Now with checklists.

Take a look at the SEMAT logo. See the spring–bow compasses standing in for the letter ‘A’? The compass is a powerful symbol. Compasses are found in the symbolism of the Freemasons. And of the former Deutsche Demokratische Republik. According to wikipedia they stand for “precision and discernment” which I guess is what SEMAT want to invoke. They also stand for an idea of what engineering is all about tools, on intermediate work products, on the accidental instrumentality of what engineers do. Here's Alastair Cockburn's Detailed Critique of the SEMAT Initiative from 2010 which covers a lot of what concerns me about SEMAT very well. Nothing much seems to have improved since then. The ‘T’ in SEMAT is meant to stand for “theory” and a speaker from the floor observed that there didn't seem to be any, yet. I also don't believe that there is any ‘E’–for–“engineering” either. Certainly not in the sense I identified above.


The economics of research

The researchers may not be paying much attention to economics but it has an influence on them. While I was talking about these papers at a lunchtime session back at the office my boss, who used to be a full–strength professor of computer science, observed that my choice of interesting papers were all from Europe, and that my sense of “2nd rate comp. sci.” was likely fuelled by American papers.

American researchers are driven by their funding structures to pump out a continual stream of not–very–good papers, the so–called Least Publishable Unit. Whereas Europeans have a bit more breathing space, and in particular have the time to, as in the case of Plonka, go spend time with practitioners, or with people who don't realise that they even are practitioners, as Hermans did, or to take a long view of the industry, as Budgen is doing. 

A Strange Feeling

During several of the sessions at ICSE I was struck by a strange, uncomfortable feeling which I subsequently identified as a consequence of having a feminist moment (if you'll allow the conceit).

Many, but certainly not all, speakers—mainly the 2nd rate CS types—spoke earnestly about these people called “practitioners” but spoke of them in a way which suggested that (1) there couldn't possibly be any of these people in the room and (2) they are other, a strange and mysterious group with peculiar motivations and interests who need to be studied, and handled, carefully and (3) they need someone strong and capable to come and help them out—all in their own best interests, of course. Ah! practitioners! Dear, silly, practitioners! You have to love them but (as we all know, don't we?) they can't really be trusted with important jobs. Too flighty and erratic. Energetic enough in a blundering sort of way, but so muddled and confused.

It took a while to realise that they meant me.