Crowdsourcing, Pair Programming and Code Review for Unit Testing


That last post on sorting primitive arrays in Java succeeded beyond my wildest dreams. But not in a way I had anticipated.


The best part was the replies with suggestions for improved unit testing, both at the specific and general level. That is, crowdsourced unit tests.

I got fantastic feedback from David R. MacIver, which I’m incorporating into our code.

I also got some good general advice. Particularly, “Did you look in the libs for something that does what you want?” (yes) and “Did you profile before setting off on this perhaps ill-advised specialization?” (not yet, but with qualifications).

Code Review

This reminds me of what many of my friends and former colleagues at Google have said is the very best part of Google’s engineering practice: having code review by a peer before any commit. That seems Draconian to me, but hey, so did source control when I first heard about it. The Google engineers say it works because of reciprocity, coders have to review if they want their code reviewed. I can’t even imagine how great it’d be to have Martin Jansche or Mike Riley reviewing my C++ code.

Pair Programming

I spent four or five afternoons pair programming with Ben Goodrich lately. He knows R back to front, and I’ve had some experience designing and coding GUIs. So we sat down together and built a GUI (using gWidgets, a really cool pacakge) for mi, a multiple imputation package that Ben completely rewrote (but hasn’t yet released).

The bottom line is that pair programming is fantastic in a number of situations. One is like we had, where there is some complentarity in skill sets. The second, which is what I usually had at SpeechWorks, was when a newbie (me) was assigned to work with a veteran (typically Sasha Caskey for me). At LingPipe, Breck and I often sit down for an hour or two to bang something out. A third situation in which pair programming shines is when the work is painstakingly detail oriented and it’s hard for one person to keep track of all the moving pieces and keep all the parts of what’s going on in their head.

In talking to Matt Hoffman about pair programming as we walked back to the A train one evening, he said that he felt pair programming was perhaps the best use of time, but perhaps not the best use of energy. Why’d he say that? Most people’s reaction is that pair programming would be relatively relaxing, but unproductive as measured in person hours.

Little do the uninitiated know that pair programming is right up there with qualifying exams and academic job interviews in the exhausting department. It’s exactly the opposite experience from in-the-zone debugging when you find it’s 6 AM and don’t know where the time went.

The thing about pair programming is that it only rarely gets interrupted, so it’s long hours of intense, continuous concentration. And you often have to explain what you’re doing as you go along. In essence, you have to give what the psych folks call “protocol“. Herb Simon, my idol, was a big proponent; Violetta Cavalli-Sforza, while working with Herb at CMU, had me give protocol while solving GRE analytical problems. As effortless as I find solving simple logical puzzles, doing it effectively while giving protocol was nearly impossible. Sort of like patting your head and rubbing your stomach.

In pair programming, you don’t get stuck and start web surfing or answering e-mail (or texting or whatever). You just steam through all the hard problems, which can require significant energy and lots of decision making. With two people looking at every line of code, you catch most of the syntax mistakes and little logical mistakes like off-by-one errors before you even compile. It’s very hard to cut corners with another skilled programmer sitting next to you.

Oddly, what doesn’t happen, is that you don’t get stuck like Dr. Seuss’s Northgoing and Southgoing Zax. Compromising on how to do things is the easy part.

If you haven’t ever pair programmed, I’d highly recommend it. It’s properties will almost certainly confound your expectations if you’re like everyone else I’ve ever talked to about it.

3 Responses to “Crowdsourcing, Pair Programming and Code Review for Unit Testing”

  1. Ken Williams Says:

    I’ve only pair programmed once, as co-pilot, and my partner kept checking her email, going to her RSS feed, etc. every 30 seconds. It was intensely frustrating. I should try it again sometime, I suppose not everyone is so brazenly silly.

  2. Jochen L. Leidner Says:

    One thing worth pointing out is that pair/peer development (construction of new code by a pair of developers) is different from peer (but not pair) review of code (code is written by one, and reviewed by a peer before your commit or push).

    Peer development is more fascinating with two like-minded developers, and it’s also more frustrating with developers who approach problems differently. Whereas pair development Peer review is more like auditing, where one party gently probes the other’s decisions made.

  3. Bob Carpenter Says:

    Thanks for clarifying. I didn’t actually go into code review in any depth because I’ve never really been in a place that did extensive code review. I presume that like all kinds of feedback, when it works well it’s highly constructive.

    I have had textbooks and journal articles copy edited, which is also very illuminating. It’s also good or bad depending on their clash with your style. For instance, MIT Press has a lighter comma style than Cambridge University Press, as well as disallowing the authorial “we”. I really didn’t like MIT changing all of my “we”s and “us”s to “I”s and “me”s. MIT was also hyphen crazy — they had a different notion of what was properly idiomatic (e.g., they wanted “phrase-structure grammar” arguing that “phrase structure” is not a common enough term to be parsed without a helping hyphen).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s