The social aspects of Pair Programming


Pair Programming Illuminated describes a number of social aspects that can influence pair programming. I have been pair programming for more than a decade now and have experienced its pros and cons.

Pair programming is often sold as a way to improve code quality. I can assure you this is not always true. Lauri Williams and Robert Kessler have written a book that is one in its kind. They explain how differences in skills of programmers can influence the working atmosphere.

I have experience that not only the working atmosphere is influenced by the differences in skills, but also the code quality and that this can lead to low quality code even when very experienced and skills programmers are pairing up.

I have noticed that pair programming is not for every programmer. I have been studying social psychology for several years now and I believe I have found a confirmation of this thought.

Concepts from social psychology

There are two social psychology jargon concepts I want to introduce here: social facilitation and social loafing.

Social facilitation refers to tendency of an individual to show better performance when in close proximity of other people. The individual will more likely be stimulated to perform a task then when working alone. Even passive presence of other people can be enough to get into action. The task will also be executed with better performance. The opposite effect can also occur when then task is perceived as too difficult. In this case the task is likely to be executed less well than in the individual case.

Social loafing refers to the tendency of an individual to perform less well when he/she is part of a group compared to when working alone. This particularly happens when it is less clear what the individual contribution to the task is for that individual. This can be eliminated by adding elements that clearly identify the individual contribution.

There are two known effects of this: the free-rider-effect and the sucker-effect. The free-rider-effect occurs when an individual will put in less effort, because he believes someone else will probably put in more effort. The sucker-effect goes even one step further and occurs when an individual has the feeling that others in the group are behaving like free-riders. Why on earth would I put in more effort when others don’t?

What does this have to do with pair programming?

My personal perception is that it is better to perform simple programming tasks on your own. Individual team members will be more motivated and are more likely to do a good job when simple programming work is split and divided over the team. I have noticed that the lead time is usually higher when an easy programming job is done by a pair. In such a case pair programming is too expensive. The same job may easily cost twice as much than when performed by an individual.

Complex programming tasks on the other hand can better be performed by a pair. In this case the individual performance is of less importance and the combined performance will be better. The cost for performing a complex task will be lower compared to individual cost. When a complex task is performed by an individual he may experience pressure from the group and this can negatively influence the end result.

From this I conclude that pair programming for easy programming jobs can be better performed by an individual and that complex programming tasks (that may involve design and architecture work) can better be performed by a pair.