Pair-programming is a core practice of Extreme Programming - arguably one of the practices that XP is most well known for, and for good reason. The jump from working in an entirely solitary fashion to having another person watching your every move can be pretty scary if you’re not prepared for the change in social dynamic. But not everyone effectively pairs with everyone - so where should we draw the line between “promiscuous pairing” and “efficient pairing”?
Giant Robots?
So I really like Pacific Rim; giant robots fighting giant aliens is an awesome basis for a film, and it contains a neat analogy to pair-programming. These giant robots, Jaegers, generally can’t be piloted by one person - the neural load is just too high for a single pilot to handle. Consequently, they introduce a two-pilot system and mitigate this burden via a psychic link called “drifting”.
Sharing the cognitive load with someone else makes solving problems easier - the same principle that guides pair-programming. Here’s the snag though - you can’t just “drift” with anyone, you need to be compatible, and therefore the effectiveness of that pair depends on their “compatibility”.
So it should make sense to pair people who work well together so they can do what they do best - in this case killing aliens writing good software. But does it?
One of Us
The intuitive way to “optimise” pairing partnerships would seem to be to group people who work well together into a team, but this method of thinking exposes a number of flaws.
-
Stagnation: Keeping a group together who think (and in this case code) in similar ways runs the risk of narrowing the collective knowledge of that team over time unless the team actively tries to combat this.
-
Groupthink - After a period of time with the same team members it’s easy to passively drift into not only a stagnant base of techniques but for actual responsibility to be eclipsed by the concept of “The Team” - abstracting developers away from individual culpability can be dangerous.
Compromise
The way we try to actively combat these problems is to introduce team rotation - at Unruly, we have team rotations once per quarter. This means that if someone wishes to join another team (for whatever reason) they are most of the time free to do so - there are exceptions, for example prior to a major product release the team might decide on a “movement freeze” in favour of retaining knowledge at a critical time. Such decisions are up to the discretion of the team in question.
We encourage rotation for a number of reasons. It keeps fresh blood flowing around the teams - not just in terms of technique, but also different personalities - dovetailing nicely with the XP principle of Collective Ownership. We’ve run into situations where one team has already solved a particular problem and regular team rotation ensures this knowledge is spread around.
Recently we’ve started Mob Programming which has enabled us to bring other team members into our programming sessions like our UX specialist or Product Manager.
Conclusion
We’ve found that the way to avoid the local maxima of “optimal” team configurations is to introduce infrequent but regular rotations into the team. This is made easier by hiring new people, but it’s often the case that new hires are started off in the team for which they are the best “fit” - not a huge risk but can be problematic.
Pairing is a soft-skill, but a skill nonetheless and an important complement to hard development knowledge, and the only surefire way to get better at it is to do it as much as possible with as many different people as possible. Some of these people might be “incompatible” with your own style of development, but that doesn’t preclude the possibility of learning from them.