My last two blog entries, Effectively Exploring Exploratory Testing and Reckless Test Automation covered two Agile techniques and the controversies surrounding their acceptance in the industry. I am continuing my discussion of practices championed by Agile approaches by further exploring Pair Programming (PP), the extreme of Extreme Programming (XP).

Pair programming can best be described as two programmers working together at a single workstation to develop software. Normally pairs switch roles and partners several times a day to reduce redundant work and the negative effects of incompatible pairings. While XP vehemently advocates this “shared-knowledge” practice, most who have not tried it are skeptical of its productivity claiming it to be an inefficient use of programming resources. Are there situations in which PP just isn’t as cost-effective? In essence, its argued that two programmers are doing the work of one. Can a pair really outperform two individuals?

Research into pair programming shows that pairing produces better code in about the same time as programmers working singly. Working on complex tasks, with two brains (and two pairs of eyes) is one obvious benefit of PP. In addition, pairing is a cost-efficient way to allow junior programmers to witness the skills of their senior partner through line of sight learning. There is also an overwhelming sense of peer pressure so partners are disciplined to apply themselves that much more. When you have someone sitting next to you it’s far easier to stay on track…just as long as “staying on track” doesn’t interfere with the occasional Test Early blog break.

Are two heads always better than one? Remote software development, along with workplace flextime and telecommuting are becoming increasingly popular. Although it is possible to pair program remotely its best if the core work be done in the same location. Of course, getting agreement on the coding standards may result in conflict for the pair. Most importantly though, the style of PP just does not suit everyone’s personality. It really does depend on the “chemistry” of the pair. While some people may prefer having another programmer constantly sitting over their shoulder other programmers absolutely loath this idea. Traditionally programming has been taught and practiced as a solitary activity. Imagine sticking an introverted programmer into this noisy, extreme, day in and day out environment. For limited periods, programmers can adapt to this setting but over long periods of time the process may seem exhausting to them.

In the end it’s all about acclimatizing your development process to what works best for the people that you have. When instituted in the right setting and with the right pair, Pair Programming will be advantageous. Demanding pairing to developers who refuse to change their coding habits just won’t work. In certain circumstances, some things just aren’t meant to be shared.