Pair programming is hard

And whether it works or not depends on you and your team.

Pair programming. People hate it or love it. Plenty of other authors covered the generally accepted benefits and drawbacks. I had the opportunity to work in a company that started as a full-time pair programming shop and half way through my time there abandoned the practice almost completely.

What is pair programming?

Pair programming is when two developers work together on the same workstation. One is traditionally called the Driver and the other one is the Navigator. Driver is coding and Navigator is checking the code, offering advice, looking for bugs and thinking ahead.

It can be done remotely as well. The only thing needed is a decent internet connection, headset and any screen sharing software.

In the beginning, we paired on every task. Only a few support tasks were left for people to do alone after they mastered them. We did pairing both locally and remotely.

Pair programming suffers from diminishing returns

Good developers following good practices usually end up writing good code. But not everyone knows everything. If you pair two programmers that both know something the other one doesn’t, the pair becomes more productive. In the end, everyone’s knowledge should reach the same level.

And that did happen to my team. The more we paired, the less I felt we needed to pair. There was still the benefit of producing safer code with less bugs, but the cost was higher.

Pairing limits outside influence

In a pair, it’s hard to just go and read something online. Find a different solution to a problem, different from the others you have tried.

The code such pairs produce might be better and safer then what the two individuals would produce on their own without consulting the outside world. However the individuals are more likely to go and see what the community came up with.

Innovation and more experimenting were the greatest changes after no pairing. Not that there wasn’t any innovation when pairing, but it was limited.

Pair programming requires discipline

One of the best practices is that Driver and Navigator should switch often and pairs should switch partners often, too.

When pairing, sometimes we switched only after a task was finished. Pairs usually had a momentum and tried to make the best use of it. It hurt the knowledge sharing and the bus factor. In the end, some tasks were done by certain pairs more effectively — one of the things pairing is meant to remove.

While it is possible to pair program on any workstation, a comfortable pair programming station can be equipped with two mirrored screens and sometimes even two keyboards and a mouse for each developer.

Two screens was a good idea. But I found that having a keyboard for the Navigator increased the instances of “stealing input”. Which is very different for a proper switch between Navigator and Driver.

Pair programming requires discipline from the team. If they can’t focus on their roles, pair programming won’t work.

It’s not the right tool for the right job

There is no right job for pair programming because any task can be done in a pair. Even simple and straightforward tasks can benefit from another pair of eyes. But not every pair works well together. Pair programming is the right tool for the right team.

Some people thrive in a pair and others don’t. Pairing can be stressful, as everybody’s pace and work style are different.

Pair programming requires careful planning. Team leaders, managers and programmers who wish to leverage pair programming should build pairs and teams in a way that every developer works in a way that is best suitable for them.

The senior-junior pair benefits incur high cost

Another benefit of pairing is that it brings juniors up-to-speed quickly. But it can be costly. Juniors need to be given a lot of driving time and they usually don’t make good Navigators. Especially if there is a pressure of getting things done, juniors might end up being passive spectators.

Pairing with a junior requires significant dedicated effort from the senior. Some juniors simply need to spend time with the codebase themselves. While they are still going to ask questions, they might not need full-time pairing.

Constant feedback is indispensable

Three things are equally important — team velocity, team satisfaction and customer satisfaction.

In another team that used pair programming, both team satisfaction and velocity increased after the pair programming was abandoned. In my team, however, we couldn’t tell because proper metrics were not in place. From my point of view, both were hurt.

The team was used to pair program, which affected productivity in short term, but again without proper metrics it’s hard to say when or if ever it improved. Since my team used to assign story points to bug fixing, the overall velocity did not seem to be affected.

Changes in team satisfaction were visible soon, too. Especially after one of the seniors, who considered pairing essential, left (however I can’t tell how much was it due to not pairing).

Customer satisfaction is complex. One thing that’s easy to measure is the number of defects in the software. Pairing can often remove a significant number of bugs. One of the mistakes in our team was that we did not keep track of number of bugs discovered in new features developed before and after the decision to stop pairing was made. Such metric would be invaluable.

So does it work?

Yes, but it’s not something that anyone can do. In the right team, productivity increases. The number of defects in software and the number of complaints from customers decrease. Knowledge gets evenly distributed in the team. If everyone likes to pair, team will have lower turnover rate.

But the team has to make it work. I believe that people who enjoy pairing work in teams that were built for pair programming and dedicate a lot of effort to it.