Computer Science and Global Warming research

Last night, a mix of graduate students mostly from different areas in Computer Science, but also from Physics, Biology, and Transportation Policy at the University of Toronto’s Centre for Global Change Science got together to discuss how CS can do interdisciplinary research that helps advance global warming research. Since a lot of climate change research is done through computer simulation models, we discovered huge opportunities for collaboration. Here is a small sample:

• Optimization of parallel programming (so that researchers don’t need to wait for months to get their results)
• Data mining
• Data merging (from different models’ databases)
• Information visualization
• Machine learning
• Software practices
• Software verification
• Managing the coupling of simulation models (say, an atmospheric model with an ocean model)
• Knowledge management

This meeting was just a start –I’m sure there will soon be several collaboration projects between our CS department and other research groups. It’s an unparalleled opportunity to solve very challenging computer science problems and help solve what might be the most pressing issue of our time.

Thanks to Steve Easterbrook (my advisor) and Jonathan Lung (my colleague) for setting this up!

Who *really* killed Roger Ackroyd?

Agatha Christie’s The Murder of Roger Ackroyd was one of the first mystery novels I read, almost 20 years ago, and it’s ending got me hooked on the adventures of the detective Hercule Poirot until I had exhausted them. I know it has the same effect on other people –it seems to be one of the most recognizable novels in the genre.

Well, it turns out Poirot might have been wrong all along. In Who Killed Roger Ackroyd, Pierre Bayard blasts Poirot’s shocking solution by pointing to all its glaring weaknesses, gives us a tour through the techniques by which Agatha Christie and other writers hide the truth in plain sight in their novels, discusses delusions and classical detective stories as far back as Oedipus Rex, and, in the tradition of the genre, presents his surprising solution near the end.

Though Bayard’s solution doesn’t have the shock factor of the original novel, it’s more logical, elegant, and poetic than Poirot’s –an excellent read if you enjoyed the original. Just two warnings: Bayard gives away the ending to a huge number of Christie’s plots, and the discussions on psychoanalysis and text interpretation get a bit heady at times. Whether you like that depends on your taste.

Gesundheit!

Here’s a truly charming (and gross!) little videogame. In Gesundheit, you’re a cute allergic pig outwitting big bad monsters… with your snot. The game is fun, the music is playful, and the graphics are beautiful:

Developed by Toronto’s Matt Hammill, for PC. Found via Drawn!

Theory use in Software Engineering research

In the same issue of Transactions on Software Engineering that has the pair programming study I just mentioned, Hannay et al. [1] –again from the very prolific Simula Research Lab–, give us a glimpse of the immaturity of the software engineering research field by reporting on a survey about the amounts and kinds of theories used in software engineering experiments. While other disciplines take theory for granted to guide their studies (why would a physicist look for ether anymore when it isn’t a part of any current theory?), most software engineering researchers haven’t read the memo yet:

“Of the 103 articles, 24 use a total of 40 theories in various ways to explain the cause-effect relationship(s) under investigation. (…) Several articles comment explicitly on the lack of relevant theory. (…) Most of the articles (that) use theory (use it) to justify or motivate experimental research questions. However, we found no evidence of theory-driven research, in the sense of empirically based theories that encompass and define the research questions of empirical software engineering.”

To use Kuhn’s terminology, we’re still in the prescientific stage. We will hopefully get out of it soon (that is, in a decade or three).

—

[1] Jo E. Hannay, Dag I.K. Sjoberg, and Tore Dyba. “A Systematic Review of Theory Use in Software Engineering Experiments”. IEEE Transactions on Software Engineering, 33:2, Feb. 2007.

Pair programming evaluated

A controlled experiment with three hundred paid subjects participating for a full day is flimsy evidence in the medical field, but for software engineering researchers it is huge. In the February 2007 issue of the Transactions on Software Engineering journal, Arisholm et al., from the Simula Research Lab in Norway, report on a pair programming study with 295 professional Java consultants [1]. One third of the participants worked alone, two thirds worked in pairs on the same problems.

Pair programming –that is, working shoulder-by-shoulder with another developer in the same computer– is one of those practices that has a few vocal convinced believers and a large majority of outsiders remaining silently skeptic. The standard claims are that these pairs are as efficient as individuals, or more; that they produce code of higher quality since everything is being verified as it is written; and that knowledge about the project flows better in the team since at least two people know how every bit of the system works, leading to all sorts of qualitative improvements.

The study of Arisholm & Co. explores the first two of those claims. From the abstract:

“The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly”

So no improvements in time or quality were observed. The results also indicate that pair programming produced higher-quality code in more complex problems, and that junior consultants working in pairs benefit mostly in terms of correctness, while more senior consultants benefit mostly in terms of effort.

Although it’s an unusually strong experiment, mainly due to its magnitude, it has two important biases. First, against pair programming: Most subjects had no pair programming experience (while every developer has solo programming experience), and they had to get to work with strangers, so the benefits of knowing your pair’s work style and habits did not have a chance to ramp up. Everyone that has seen team members develop trust and collaboration over time would agree that evaluating recently formed pairs is artificial.

Second bias, in favour of pair programming: The real comparison should not be against solo programmers, but against pairs of developers working on the same problems, as a team, but on separate computers. For instance, Joe may choose to work on problems 1, 2, and 3, while Jane works on the much more complex problem 4 all along. The pairs of solo programmers would need to be familiarized with each other as well, of course, so that their long-time collaboration has a chance to kick in.

Still, this is the heaviest data point in pair programming research to date, and it’s worth taking a look at it if the topic interests you.

—

[1] Erik Arisholm, Hans Gallis, Tore Dyba, and Dag I.K. Sjoberg. “Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise.” IEEE Transactions on Software Engineering, 33:2, Feb 2007.

I’m not to be trusted anymore

Jerry Rubin once said “never trust anyone over 30″, so today, in my 30th birthday, I have a public announcement:

I need to warn you, with the last throes of that candid young man I used to be just yesterday, don’t trust in me anymore, no matter what I say! I’ll turn into an unrepentant weasel any second now. I feel the cold grasp of cynicism taking hold of me and I don’t know how long will I resist…

…

Ahem. Feel free to ignore the idiocy of that last paragraph. I don’t know what was I thinking. Rubin said not to trust anyone over 30, and I am just 30. Clearly, I can be trusted for a full year still. Let’s ah… go for a coffee and discuss indie bands or whatever us young people do.

Mexican Mounties

Further evidence of the surreal nature of my country of origin:

The caption in the original reads: “Canada In Cholula: San Andres Cholula has a Canadian-style vigilance; like the Royal Mounted Police, 12 local policemen patrol the streets horseback.”

Goes in the same category as that machete protester in a Donald Duck t-shirt.

Photo from reforma.com (in Spanish).