Pair Programming Study
Last week I was contacted by Robert Plummer from the CS dept. at Stanford. He recently published a paper on a study about pair programming conducted at Stanford and is currently conducting a follow-up study for which they require professional software developers as subjects. It sounded like an interesting project so I granted his request and spent a few hours in the Center for Design Research yesterday engaged in a pair programming exercise with another randomly selected professional software developer.
We started out by filling out a brief survey about our prior experiences with and existing opinions of pair programming et al and then completing a warm-up coding exercise together. After that they handed us a 3-page description of a programming task, answered a few questions we had about it and left us alone to implement a solution. They wanted to capture as much information about the development process as possible so, in addition to recording both our displays, they had 4 videocameras watching us from different angles and each of us had throat mikes. We were provided with a whiteboard and blank paper on which to sketch or scribble anything we needed and they took digital photographs of these at the end.
The other programmer, Dan, was both friendly and competent so we got along very well. We started out by discussing possible strategies for solving the problem and then sketched visual representations of our architecture, data structures and control flow. After a break for lunch we began writing code. Despite our initial design efforts, we had to return to the whiteboard a couple of times to flesh out the details for certain parts of the code. When we had a skeletal implementation we tested it with the supplied test harness and found some nasty bugs that we had to fix before tackling the edge cases, polishing up the output formatting and cleaning up the code a bit. Along the way we made snarky comments about the quality of the provided framework, took turns at the keyboard and frequently caught each other's mistakes or made suggestions to improve code the other was writing; good times :-)
When we were finally done, the researchers had us fill out an exit survey about our experiences and interviewed us each privately about our thoughts on each other's abilities and working style. They still have a good chunk of these sessions to run before they can analyse the data but I'm hoping to learn some interesting things when they finally do publish the results. Apparently this is the first ever study about pair programming to use professional software developers instead of students or to use a challenging task that takes a few hours instead of a trivial one that was usually solved within an hour or to record and analyse the process itself in addition to just the resultant code!
We started out by filling out a brief survey about our prior experiences with and existing opinions of pair programming et al and then completing a warm-up coding exercise together. After that they handed us a 3-page description of a programming task, answered a few questions we had about it and left us alone to implement a solution. They wanted to capture as much information about the development process as possible so, in addition to recording both our displays, they had 4 videocameras watching us from different angles and each of us had throat mikes. We were provided with a whiteboard and blank paper on which to sketch or scribble anything we needed and they took digital photographs of these at the end.
The other programmer, Dan, was both friendly and competent so we got along very well. We started out by discussing possible strategies for solving the problem and then sketched visual representations of our architecture, data structures and control flow. After a break for lunch we began writing code. Despite our initial design efforts, we had to return to the whiteboard a couple of times to flesh out the details for certain parts of the code. When we had a skeletal implementation we tested it with the supplied test harness and found some nasty bugs that we had to fix before tackling the edge cases, polishing up the output formatting and cleaning up the code a bit. Along the way we made snarky comments about the quality of the provided framework, took turns at the keyboard and frequently caught each other's mistakes or made suggestions to improve code the other was writing; good times :-)
When we were finally done, the researchers had us fill out an exit survey about our experiences and interviewed us each privately about our thoughts on each other's abilities and working style. They still have a good chunk of these sessions to run before they can analyse the data but I'm hoping to learn some interesting things when they finally do publish the results. Apparently this is the first ever study about pair programming to use professional software developers instead of students or to use a challenging task that takes a few hours instead of a trivial one that was usually solved within an hour or to record and analyse the process itself in addition to just the resultant code!