Skip to content

Category: pair programming

  • warning: Invalid argument supplied for foreach() in /home/artemmarchenko/ on line 1270.
  • warning: Invalid argument supplied for foreach() in /home/artemmarchenko/ on line 1270.



Pair programming. What researches say on the costs and benefits of the practice.

August 19, 2008 by Artem Marchenko

Photo courtesy of BrianScott@flickr
Last week the entry on risks on solo programming attracted a number of comments debating the value and costs of pair programming (PP). My personal observations and discussions do support the claim of better quality and faster development, when pair programming is done the right way and learned under the coaching of experienced mentor. However, these are just my personal observations and I was rarely focused on measuring and "average" team, most of my observations were based on teams who did want to pursue the path of continuous improvement and were interested in learning how to do the practices the right way.

Gathering data

Anyway, I promised to gather a bit of scientific evidence and here it is. This is not an in-depth scientific review, but rather a result of couple of hours spent on browsing Google Scholar and IEEE Xplore and skimming through the top articles related to "pair programming defect rate" and "pair programming quality". Most of the articles happened to be about the students doing pair programming.  Taking into account the industrial context of original discussion, I decided to ignore most of the articles that involved only students. Note, that for purity I was trying to examine solely the effect of pair programming on quality, defect rate and corresponding costs.

Five risks of solo programming

August 15, 2008 by Artem Marchenko

Woman hiking a slot canyon in the Narrows, Zion National Park  
Pair programming is one of the most debated practices of the Extreme Programming. Historically, programming used to be a solitary activity that required high concentration and even isolation. The best programmers know how to get into the metal state called "flow" or "zone", in which the undisturbed mind is able to efficiently focus on the code and make highly creative and efficient design decisions.

While "zone" is indeed highly valuable and learning how to deepen into zone as a pair might be more difficult, than learning how to get into flow alone, the truth is that despite the comfort of the long time status quo, solo programming is just too risky and in the end might cost quite some more money for the company. There are many risks of solo programming, here are the top five that come to my mind.

XP Practice: Pair programming

April 18, 2008 by Artem Marchenko

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

Minimize the review burden by applying the review on a smaller bits of code

March 26, 2006 by Artem

Peer code reviews are known friends of a good code quality. Many of the agile methods strongly recommend them. XP as usual goes to the extreme point and offers the pair programming practice, when the reviews are performed continuously.

The usual problem with the code reviews (unless you practice the pair programming) is that they are often performed after writing a big block of code and reviewers can concentrate on the micro level issues like coding conventions and style. It is important to enforce the common conventions, but it would be great to pay bigger attention to the code logic.

Best of