Practical pairing is the notion that when we pair, we do so intentionally. It’s about being conscious in our decisions to wield pairing and not fall prey to the illusion that pairing is always valuable because it is sometimes valuable. Contrary to the old adage, what is good for the gander is not always good for the goose. Pairing is just another tool in our toolbox and treating it like a hammer won’t in turn make everything else into a box of nails. In fact, doing just that does a disservice to the people we’re trying so hard to provide value for: our clients and users of the software we’re building.
Striking a balance that maximizes the value of pairing while minimizing its associated costs is difficult, though. Pairing is unlike most traditional tools in the software developer’s toolbox: object decomposition, unit testing, integration testing, design patterns, anti-patterns, etc, in that it is a social practice. This results in a dynamic that isn’t present when we work alone. This dynamic leverages the power of two minds against a task which would be more difficult and take much longer without pairing. But just because pairing is involved doesn’t mean the benefits are automatic. We have to work for them, and not every situation yields the same potential for value. And when the value seems less than the cost we should change strategies, which is exactly what Chris and I did in the opening paragraph of this post.
Before we can know how to determine if pairing makes sense we need to answer an even more basic question. What is pair programming?
Pair programming is essentially two people, one computer, together solving problems. One person is the driver who is responsible for typing the code and the other is the navigator who is responsible for providing code review. As the pairing session continues the pair routinely switches roles, the driver becoming the navigator and vise versa. Pairing helps achieve a higher code quality and reduces the defect rate of software.
The primary goal of pair programming is to not only increase the quality of the software being delivered, but to also help in making development more sustainable over time. It accomplishes this in two primary ways: first) by allowing two intelligent human beings think, talk, discuss, code, and review in an extremely tight feedback loop, and second) by naturally creating opportunities for mentoring, teaching, and learning.
These means by which pairing achieves sustainable development result in additional benefits to individual team members, the team as a whole, and the companies involved, both client and vendor alike. Over time, the speed of the team will actually increase as well, due to the continual learning, cross-pollination of knowledge, and healthier working relationships that emerge.
Another common staple of pair programming is the rotation of pairs (if your team has more than one pair). Pair rotation is simply moving people around so the same two people aren’t always pairing together. Different teams rotate differently. Some teams rotate only within a project, but they may do it by card, day, or iteration. Other teams rotate across projects by card, day, or iteration. This can be taken to the extreme in a practice called promiscuous pairing, in which pairs rotate every 90 minutes. Rotation helps in distributing knowledge amongst the entire team.
Pairing is never free, however. Simply put, a pair costs twice as much an individual. In certain circumstances the value of pairing dwarfs the cost, and this is a good time to pair. In contrast, there are times when the cost dwarfs the value. It’s in these times especially that we need to be selective, intentional, and judicious in our application of pairing.
One reason for selectivity in pairing — there are more, but this is one of the most prevalent — is that we work with limited resources, specifically budget. The budget is usually not owned by us, but by our clients, and while pairing 100% of the time keeps accounting simple, it errs on the side of maximizing cost while saturating the value. We can be better stewards of these resources.
In Part 2: Determining When to Pair, we’ll discuss a few rules of thumb for determining when pairing is practical.