(Do not) aim for the eagle

The Second Workshop on Software Research and Climate Change is only days away –it’s scheduled for this coming Monday, May 3rd. It will take place in Cape Town, South Africa, co-located with ICSE, and I’m going to miss both the workshop and the conference. I plan to attend remotely to some of the afternoon sessions, but I don’t have my hopes set high for the connectivity of the conference centre.

In any case, Jon Pipitone, Val Cortes and I decided to write a position paper for the workshop. If you read Jon’s blog you already know his take on it; I have a few other things to say.

First, a bit of context. Thanks mainly to Steve’s efforts, we’ve been trying to build a community of software researchers interested in using our time and skills to fight climate change. The community is still at a very early stage in its formation, still setting its research agenda and projects. For this second iteration of the workshop, as well as for the first, participation has consisted mainly of brainstorming ideas for collaboration, which is all fine and good, except for one thing: I feel we might be unconsciously bringing our academic habits into this community, and they won’t help us here.

Let me explain this. On one hand, climate change is both an urgent threat, that demands decisive action within the next decade, and a messy problem, involving science, politics, activism, economics, and much else. There are many groups with vested interests, many gritty details. On the other hand, we as academics are used to dreaming up big ideas and letting someone else worry about their implementation; it doesn’t bother us that technology usually takes a long time (about 25 years) to transfer from the lab to society; and we’re too busy with our own petty politics to come out of the tower and get our hands dirty with real problems. So I fear that when we try to do something about climate change, our reaction is to first come up with some half-cooked idea that might (but probably won’t) work thirty years from now, something nice and abstracted and elegant and conveniently close to what we were doing anyway; second, write it up; and third, move on thinking that we’ve done our part to save the world.

Jon, Val, and I were talking about this, and thought that this was the time to try and communicate this message to the folks in the workshop. However, we felt that if we stated this straight up, we would probably be ignored. So we decided to try something different: to state the opposite of what we really wanted to say, in terms so naively absurd that people reacted against that message and in favour of what we really wanted to share with them.

The result was the paper “Aim for the eagle: Making the best use of our software research skills to fight climate change.” It’s relatively short (3 pages) and I think if you know it’s meant as parody you’ll enjoy reading it. It starts sane but it soon gets weird, and by the middle of the second page it gets lost in Crazytown, proposing, for instance, to use software fault detection tools to CT scans of our brains so that eventually neurologists could “rewire” our heads so that we understand the unintuitive aspects of climate science (and then take immediate action against global warming of course). For the (we thought) unlikely event that our readers wouldn’t get the satire, we added a note at the end to help them get it right.

Well the problem is people took it seriously. One reason may be that readers are not expecting to find this kind of paper in what is supposed to be a straightforward workshop. Another reason, pointed out by Robert “Jack” Will, is that many of the statements the paper makes “are very similar to what other papers in the field say.” (This is rather sad for software research in general, as any field that can’t distinguish parody is probably in trouble.) A third reason, according to Greg, is that we simply failed at doing proper satire: the paper might have been too subtle, too mild, to trigger our readers’ sarcasm detectors.

I guess if people take this kind of paper seriously, but react against it anyway, things are fine. Some of the reactions we’ve received are like this, and I’m happy for that. But with the workshop just days away, I’d like to make a plea to its participants: focus on short-term, tractable problems that solve real needs for real people at the front line of the fight against climate change. And please don’t treat the workshop like a Science Fiction convention! We’ve got a decade or two to turn the ship around, and the sooner the better.

About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.
This entry was posted in Academia, Activism. Bookmark the permalink.

5 Responses to (Do not) aim for the eagle

  1. I don’t know. I think you hit 2 out of 3 in your scope section. Perhaps this was unintentional on your part but it may have thrown people off the scent.

    In particular, while UML as a climate modeling tool is silly, a much higher-level model description language aimed at continuum modeling still seems to me a feasible goal, and for pretty much exactly the reasons you stated.

    And as for an IDE for developing policy, why is that far-fetched? A simple instance has already been used for negotiations among stakeholders for water rights in Texas. For more complex issues, an array of models that could accept rule inputs might be just the thing. If only we had better economic models.

    I’m not buying the prosthetic brain, though.

    • Jorge Aranda says:

      You’re right, Michael –those projects, or a modified version of them, sound appealing and useful. But it’s a matter of implementation. As far as I understand, from the work of Jeff Carver, and from Steve and Jon, climate modelers aren’t going to ditch their Fortran and their text editors for an unproven cutting-edge programming tool (never mind that model-driven development is probably decades away from being a feasible alternative to the status quo). So this might be a great project to get funding for, but not, I think, a good use of a Worried Scientist’s time.

      What bothers me is that we, as software researchers, grab whatever it is we are working on anyway and claim that we can apply it in a domain we know nothing about. This is also the case with the “design patterns for policy making” project: surely any researcher that coming out of nowhere tells politicians and activists that they should be talking in terms of Factory Methods and Iterators will come across as arrogant or naive?

      But our examples should’ve been more extreme to bring in the message. The project you mention, where some sort of software tool helps negotiate climate-related policy, is precisely the kind of thing we want to see more of: well scoped, with stakeholder involvement, with tangible outputs. If it works, we can start thinking about scaling it up. I think that’s the way to go.

  2. Pingback: The IROP paper | Catenary

  3. Pingback: The IROP paper - It will never work in theory

  4. Brigette says:

    Quality articles is the crucial to attract the users to pay a quick visit the site, that’s what this web site is providing.

Leave a comment