Recent Reading

Another bunch of papers and books:

• Sfetsos, Stamelos, Angelis, and Deligiannis: "An experimental invesgitation of personalit ytypes impact on pair efefctiveness in pair programming." Empirical Software Engineering, 14:187-226, 2009. The authors had 70 undergraduates do pair programming and measured effectiveness in terms of communication, velocity, design correctness, passed acceptance tests, and general satisfaction with partners. Half the pairs were people with similar personalities (as reported by Myers-Briggs Type Indicator, or MBTI), while the other half were dissimilar. The result: dissimilar pairs outperformed similar pairs in almost all ways. There are lots of flaws in the study—MBTI is deeply flawed, it's not clear if the study was double-blind, there are many uncontrolled confounding factors—but it's still a very interesting result.
• Draper, Kessler, and Riesenfeld: "A History of Computing Course with a Technical Focus." Proc. SIGCSE 2009. Describes a history of computing course at the University of Utah that included "period" programming assignments (such as an auction/bidding game in old-style Fortran). I think this would be very cool.
• Enbody, Punch, and McCullen: "Python CS1 as Preparation for C++ CS2." Proc. SIGSCSE 2009. Measures the impact of switching to Python as a first language at Michigan State University by looking at students' performance in the subsequent (unchaged) C++ course; there was no statistically significant difference, which is either encouraging or disheartening.
• Bollen, Van de Sompel, Hagberg, and Chute: "A principal component analysis of 39 scientific impact measures." http://arxiv.org/abs/0902.2183. The impact of scientific publication has traditionally been measured via citation counts, but dozens of more sophisticated metrics have been proposed. In this paper, the authors performed a principal component analysis of the rankings produced by 39 measures based on citation and usage log data, then cluster the metrics. The most important result is that Impact Factor (the most commonly used metric) is an outlier: it doesn't produce the same rankings as most of its competitors, and should therefore be "used with caution" (academese for "discarded").
• Boyle, Cavnor, Killcoyne, and Shmulevich: "Systems biology driven software design for the research enterprise." BMC Bioinformatics, 9:295, 2008. Describes a sophisticated third-generation architecture for supporting biomedical research. It reads like a catalog of enterprise-scale buzzwords, but that's what it takes to do modern science.
• Chen, Cheng, Hsieh, and Wu: "Exception handling refactorings: Directed by goals and driven by bug fixing." Journal of Systems and Software, 82:333-345, 2009. Describes four increasingly-useful levels of exception handling, introduces some related "code smells", describes appropriate refactorings, and presents a case study. Nice work—I'll borrow from it in my next software engineering course.
• Little and Miller: "Keyword programming in Java." Automated Software Engineering, 16:37-71, 2009. Describes a tool that translates small sets of unordered keywords into legal Java expressions by matching against context, e.g., "letter at message[i]" becomes message.charAt(i). I don't know how useful the tool would be to experienced programmers, but the fact that it works at all is an indication of how much redundancy (or entropy) there is in most programming languages.
• Allspaw: The Art of Capacity Planning. O'Reilly, 2009. Allspaw draws on his practical experience at Flickr to describe how to measure, deploy, and manage web application infrastructure to avoid bottlenecks. Unfortunately, he chose not to include even the most basic mathematical material (Little's Law, M/M/1 queues, etc.). I was quite disappointed.
• Hazzan and Dubinsky: Agile Software Engineering. Springer-Verlag, 2008. A textbook on agile software development aimed at both undergraduate classes and industrial training courses. All the expected topics are there, along with questions to ponder and references to relevant literature. Dry as toast, but I'll still borrow a few ideas for my next course.
• Monson-Haefel (ed.): 97 Things Every Software Architect Should Know. O'Reilly, 2009. Mostly motherhood and apple pie: I agree software architects (and most other adults) should know, understand, believe, and practice these things, but with only a handful of exceptions, page-and-a-half descriptions of them isn't going to make a difference to whether they do or not. On the upside, there are twice as many female contributors as there were in Beautiful Code.