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.

 

Economics?

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.

Hiring in London: Lead and Principle Consultants...

Principal consultants take responsibility for particularly challenging solutions and in demanding organisational environments. They closely interact with senior project managers, customer representatives at all levels including senior management, and guide project teams. Together with the responsible project managers, they lead technical and strategic initiatives to success, ranging from critical consulting mandates to complex delivery projects. Together with business development and business unit managers, they actively expand Zuhlke’s business and develop new opportunities. This can involve taking the leading technical role in large bid

Lead consultants take decisions and provide advice regarding complex technical systems. They closely liaise with the software development team, the project manager, and customer representatives, often with a technical background. They ensure that sound technical decisions are made and subsequently realised in state-of-the-art solutions by the project team. They can take the leading role in technical consulting assignments within their specialisation area.

The role is based in London and the majority of the work takes place in UK but on occasion training and consulting engagements may be delivered anywhere in the world.

The competitive package includes 20 days of professional development time per year.

The successful applicant will be a skilled in iterative, incremental development using at least one of Java/J2SE, C#/.NET and Adobe Flex. They will be skilled at applying test-driven development using both automated unit tests and automated acceptance/functional tests in a continuous integration environment (continuous build and dev-ops experience a plus).

They will be skilled in recognizing code smells and resolving them through refactoring. The successful applicant will be able to elicit requirements as User Stories (experience of “story mapping” is a bonus) and estimation of effort using Planning Poker and Wideband Delphi. They will be skilled in coaching and supporting a development team to effectively self-organize while maintaining transparency and control of rapid development using techniques from Scrum, Kanban, Extreme Programming and other Lean or Agile approaches.

Experience in a leading role like Scrum Master is required. They will be experienced in coaching individuals and teams in effective use of current good practices in all the areas mentioned above.

Experience delivering classroom training in technical practices such as TDD or build management techniques and a track record of technical publications and conference presentations a plus.

Apply via LinkedIn, or drop me a line.

New blog for complexity study

My continuing investigation into the effect of TDD on code complexity (and maybe other things, too) will continue on this new blog.

Agile has little to say about Projects

At the 2011 UK Agile Coaches Gathering at Bletchley last week I convened a session about the desire for (larger) organizations to execute "projects" but the desire of people working in them to use "agile" techniques. I perceive a contradiction there.

Agile has little to say about Projects, a photo by Keith Braithwaite on Flickr.

For the purposes of the discussion I define a "project" as a management structure with a start date, and end date, a budget and a goal. (It says "goal", but subsequent scribbling makes it look as if it says "goat", prompting one of my colleagues to quip: pick which one you want to sacrifice!)

My contention is that when people talk about managing Agile work they generally mean Scrum or these days Kanban (or something very much like them) and that these techniques talk mainly about the steady state of product development and how to control that. They have relatively little to say about what happens at the beginning of a "project". How to get one signed off, for example. Kanban seems particularly weak on this. Nor what happens at the end of a "project" when a set of features go into production. Scrum seems particularly weak on that. As a side note, when I first started working with banks it took me a long time to properly grasp that when they talk about the "delivery" phase of a project they don't mean the relatively trivial bit at the front where the programmers write code.

So, the conclusions of the group were that projects exist as a management structure to mitigate a certain kind of risk in a certain way. As such, I would not agree with this tweet (in reply to one I sent about the very session:

The concept [of a project] is superfluous as it does not add business value.

the concept seems to persist as (some people) believe that having projects allows them to protect money. They might be mistaken: thinking about risk in software development is often wrong, but the idea of a project cannot be dismissed out of hand.

The group observed that different stakeholders have different concerns at different size and time scales, and these are nested. Scrum and Kanban talk mostly about the innermost few layers of the onion.

There was a concrete recommendation: when communicating from the inner part of the onion (smaller scale, shorter time frame) to the outer, do not talk about "iterations" or "cadence" or much of anything time based. Talk about money: pay something in this range, get something in that range.

Agile Charlatans

At the 2011 UK Agile Coaches Gathering at Bletchley last week I convened a session which was prompted by comments like this one from reddit user grauenwolf:

I used to think people like you were quacks, but now I see that there are teams that really need your services.

Grauenwolf and I have both been on reddit or a good long while and we've had a few...full and frank exchanges of opinion about the merits of this thing called "Agile". The issues I wanted to address in the session were: what causes competent professionals like grauenwolf to think that the sort of people who would go to something like an "Agile Coaches Gathering" are quacks, and what changes their mind? How might we do less of the former and more of the latter?

The output is captured here:

The "Agile Charlatan" Problem, a photo by Keith Braithwaite on Flickr.

It needs some explanation, though.

"Quack" is an evocative word. "Snake-oil salesman". "Charlatan". We felt that these words appeal to an analogy something along these lines: Agile consultants are like bogus medical practitioners.

The poster shows a 2-by-2 matrix (naturally!): well or ill against conventional medicine or alternative therapy. The model is that conventional medicine is mainly for people who really are ill and need to get better, while alternative therapy is mainly for people who are basically well but feel entitled to be "well-er".

Yes, that is quite cynical. We did talk about the fact that some alternative therapies do work, for the things they work for, but when that happens it's not for the reason that the practitioner thinks. And we talked about how some conventional medicine is not nearly as well founded as many people would like (you) to think. But, bear with me.

So, the top right and bottom left cells of the chart are the exemplars. Bottom right is the really bad place: trying to treat a mangled road traffic accident victim with a very, very, very dilute solution of London Bus, for example. Top left is pretty bad too: pushing pills for restless leg syndrome and things even less needing of allopathic intervention.

It seems that there is a problem with some kinds of Agile coaching or consulting or training or certification practices. They could be trying to address a really serious organizational problems with techniques that cannot possibly help (and maybe they even know it), or they can be barging in to teams that are functioning perfectly well and crashing about the place changing things that don't need to change.

How could we recognise these cases? Maybe this way:

1. conventional medicine often leads to treatment regimes that are quite unpleasant
2. people often need to be talked into consulting a conventional medic (partly because of [1])

vs

1. alternative therapies are often really rather enjoyable
2. people often self-refer to an alternative practitioner (partly because of [1])

How to avoid breaking a working team by spuriously making them "Agile"? Watch out for one-size-fits-all solutions. Watch out for inflexibility, a rejection of new ideas (on the part of the consultant or coach).

How to increase the chances that you're really helping? Look for objective evidence of improvement, change your behaviour based upon that evidence.

The final question we came up with extends the analogy. If Agile coaches are a bit like certain kinds of medical practitioners, then what is the equivalent for us of public health?

No More Than Two

London’s “convenience” stores are replacing staffed checkouts with self-service robots. Some of these offer lessons in user interface design painful to behold.

This evening I watched someone attempt to use one to buy paracetamol. The particular self-service robot checkout that I saw presented the user with a message very much like “paracetamol sale: you may only buy two packs” above a yes/no button pair. What is the casual paracetamol buyer to make of this? I watched with interest as my co-emptor pondered this. And then she did the only reasonable thing: she went and got a second pack. After all, it does say you may only buy two packs.

Quite what anyone is supposed to make of the yes/no buttons following a statement not a question I don't know.

The really sad thing is that, apart from the shame of confusing your customer, the behaviour I saw here—which I believe is the only reasonably response to the message from the robot—is the exact opposite of what is intended.

fixed-length iterations: a transitional practice

I find it had to think of a development practice that isn't almost certainly a transitional practice. Configuration management, maybe.

Anyway, Scrum, XP, and all the rest I've come to understand as each a record of a reaction against some bad condition, with transitional practices to get a team away form that condition to a better one. Fo example, as Michael Feathers says in this post, regular, fixed-length Iterations require (and enable) a certain kind of discipline, force a certain set of tradeoffs. And maybe doing that can help a team a lot. And maybe not, as the case may be.

That doesn't mean that, once the use of that practice has taken the team away from the bad condition then no further change to practices can be beneficial. In the specific case of regular fixed-length iterations I mainly see the application being to teams moving from a condition where no-one ever has any idea at all when anything is going to be delivered to a condition where everyone always knows a date when something is going to be delivered. In many settings that would be considered a major improvement by those paying the team. And consistently working that way is a great way for a team to gain the trust of the business.

Once that trust is established, and once the conditions are in place for frequent delivery, what need for the fixed-length iterations? I suspect that what worries a lot of people who've seen the transition from chaos to iterations is that they can't imagine a world without iterations which is not also a (return to) chaos. Michael suggests an experiment:

Suppose that you had an iteration of one week, followed by an iteration of 2 days, followed by an iteration of 1 day, followed by an iteration of one-half a day, and so on. If you still had your sanity at the end of this process, would you have learned anything? I haven’t tried it with a team yet, but here’s the thing that I hope would come across: if you apply enough ingenuity and you’ve acquired enough skill, you can deliver business value in shorter times than you can currently imagine.

That would be cool. Of course, the Kanbanista's seem to suggest going straight to that world in one step. And maybe that can work in a certain setting, and maybe not. The idea scares me, whe I look at most of the teams I help.

The aspect of this sort of thing that really interests me, though, is this: if what the Certified Scrum Masters say about software development living on the “edge of chaos” is right and if what the Cynefin people say about that being exactly the place where “emergent practice” lives then by their own argument, we would expect Scrum to consist of mostly transitional practices.

Fixed-length iterations (excuse me, “sprints”) seem like a good candidate to be one.

Government IT projects: who can politicians listen to?

As you may have heard, the UK has at the time of writing a rather confusing new government. We, and I suspect, they are still trying to understand what this means.

One thing that it might mean is an opportunity for government departments to change the way they deal with their IT suppliers. Recently (ie during the Labour administration we had since 1997 until 2010), it hasn't gone well.

• Accenture build a system for the RPA: not fit for purpose, £46.5 million overspend
• BT, Fujitsu and others build NPfIT for the NHS: not fit for purpose, £10.4 billion (with a “b”) overspend
• Fujitsu build an information system for magistrates courts: £342 million overspend
• Cap Gemini build PRISM for the FCO: not fit for purpose, £34.5 million overspend

And so on. It has been estimated that the ten worst IT project failures under Labour cost the country around £26 billion. That's half the annual budget for schools.

So, a new government setting out to tame a spectacular deficit might want to bring these projects under control. Unfortunately, they get their advice from places such as Fujitsu, the very firms who do so well form these failed projects. Says Fujitsu's marketing director Simon Carter of discussions held with the Conservatives when they were still the shadow cabinet:

[the Conservatives] began to take on some of our suggestions, as they came to better understand government IT. For example, their proposal to cut IT contracts into smaller and shorter chunks was dropped as they realised they would have to act as system integrator to each of these smaller projects.

What is the taxpayer to do in the face of this sort of thing? Particularly the well–informed taxpayer who knows full well that in no way whatsoever is this argument from Mr Carter valid.

At this year's Spa conference there was a Birds of a Feather session about this issue. Some of the signatories of this petition—a petition only 62 signatures away, as I write, from the 500 needed for it to have anyone inside 10 Downing Street pay any attention to it. If you are a UK resident and would rather that the new government were not wasting money on entirely avoidable IT project failures I urge you to sign the petition and to urge others to.