What Is Pair Programming?
Pair programming is a practice in agile software development where two programmers share a workstation. This includes a single computer. One programmer (called the driver) writes the code while the other (the observer) watches, reviews, and provides guidance. The two programmers switch roles frequently. Sometimes as often as every 15 minutes.
Note: An engineering team can implement pair programming remotely. The driver and observer can work together in different locations if they have screen-sharing capability.
What Are the Benefits of Pair Programming?
There are several reasons that some agile development organizations choose to implement the pair programming approach. Here are some commonly cited advantages.
1. It reduces bugs and other errors.
According to a study conducted by the Association for Computer Machinery (ACM) and the University of Utah’s Computer Science school, pair programming resulted in code with 15% fewer defects.
Having a real-time check on their work by another programmer can help coders identify bugs, typos, and other mistakes that they might have missed if they were working alone.
2. It increases the team’s overall knowledge level.
As the Agile Alliance points out, another benefit of pair programming is that it leads to better diffusion of knowledge across the development team.
Imagine pairing a coder new to the team with another programmer who knows the subject matter well. Working directly alongside the knowledgeable programmer, the other coder will gain expertise more quickly than by working on tasks alone.
3. It boosts team cohesion and job-satisfaction levels.
According to research cited in another academic paper, Strengthening the Case for Pair Programming, —96% of pair programmers enjoy their job more than when they code by themselves.
One reason for this is that it adds a social component to a traditionally solitary and isolated role. Also, professional pair programmers say that their confidence in their work goes up when they work side-by-side with another software developer.
Additionally, pairing programmers to work together can increase the team’s cohesion, trust, and respect. Over time, this increased sense of teamwork can improve the overall quality of the programming department’s output.
What Are the Pitfalls of Pair Programming?
While there are several benefits to pair programming, this approach to software coding also has several potential downsides. Here are a few.
1. It is more expensive than solo programming.
Putting two programmers on every coding task will increase the overall costs of that development work.
Many businesses mistakenly assume the costs would double—two programmers’ salaries versus one for the same output. But because two programmers can collectively work more quickly and fewer mistakes than one programmer coding alone, the actual cost increase is less than double. Nevertheless, an organization should keep in mind that this software development approach will require a higher budget.
2. It can be counterproductive for certain types of coders.
One best practice in pair programming is that the two coders maintain an ongoing conversation. That’s why this approach is often called “programming out loud.” Although talking through their thought processes with a colleague can help some programmers, it can be counterproductive for others.
Shy people, introverts, and coders who prefer to work quietly might all find pair programming slows them down or undermines their work quality.
3. It can undermine innovation and creativity.
If the two programmers paired together for an assignment have genuine chemistry, develop a sense of trust, and complement each other’s skillsets, their teamwork can lead to innovative and elegant code. But if the pair don’t form that type of ideal match, having them work together could prevent their ability to find creative solutions.
One reason is that Programmer 1 must persuade Programmer 2 to try an innovative idea. They will spend time trading places as the driver, which means both programmers will have to understand the plan and believe it can work.
If Programmer 2 resists the suggestion, or if Programmer 1 is too shy or self-conscious to propose the solution in the first place, the innovative idea won’t have a chance to flourish.