Pair programming is one of the technical practices from Extreme Programming (XP). I have observed that pair programming works best when either member of the pair are in discovery mode. If there is little discovery going on, by either of the developers, there is little point in pairing.
Pair Programming for Discovery
pair programming works best with a large uncertain search space of problems and solutions. the closer to a solved problem, the less it helps
@KentBeck, 4 Oct 2012
Kent Beck is the author of the original XP book, so he clearly knows a thing or two about pair programming. Kent tweeted last year that pair programming is best with large uncertain problem spaces.
I would go even further. From my observations of teams using pair programming, pairing works best when either member of the pair are in discovery mode. In other words, at least one of the pair are dealing with a large number of unknowns, whether that is to do with the business domain or the technology.
Common examples of where at least one of the pair are in discovery mode are when:
- A pair of established team members are exploring a new area of the product
- A pair of juniors are trying to solve, together, what might be a straight forward problem for a senior
- An existing team member is pairing with a newbie to bring the new comer up to speed on the technology and/or domain
Solo Programming for More of the Same
In the first two cases both partners are operating in discovery mode. But in the third example only the new comer is operating in the unknown. Pairing is still very useful here as it significantly increases the ability of the team to ramp up.
If the problem is well understood and so the solution fairly obvious then pairing is of relatively less value.
There is however another reason to use pair programming … people might just prefer operating like that. 🙂
I think this is a common management misconception. Having senior devs pairing is NOT a waste of time! Pairing will always lead to better quality. Less defects and better code.
An example can be something as simple as plumbing in resource strings. This is a very simple task but can be error prone due to its repetaive nature. Pairing up on this with anyone (doesn’t have to be another dev) will always lead to less defects – which cost a lot more than 30 mins 2 x dev time.
When I pair with another senior dev or architect the code we write is always improved. Better tests and more readable.
In fact good architects should be pairing up with the team regularly and cutting code.
The point is the reduced cost of getting it right first time and the maintainability of the end product.
I agree that “the point is the reduced cost of getting it right first time and the maintainability of the end product.” However I also think the reality is a little more complicated than “Pairing will always lead to better quality. Less defects and better code”.
For me everything needs to be addressed in terms of cost-benefit. Some research I was involved in found that pairing led to 84% more effort to perform tasks correctly. That is the cost. The benefit was that, for more complex systems, pairing gave a 48% increase in the proportion of correct solutions. Sounds good but the caveat on this benefit is that it was mainly realised by juniors. For simpler systems there was no change in the proportion of correction solutions, i.e. pairing didn’t help quality. In summary, clear cost but benefit mainly for more junior folk working on complex systems. My observations in the field backs up these findings.
Which brings me back to my point about discovery mode. Juniors are mostly in discovery mode hence often benefit from pairing. In new areas even a senior becomes a junior for a while. In these situations I’m willing to incur the extra cost of pairing. I encourage pairing.
Not that I discourage pairing in other situations. In those cases I leave it up to the developers to decide whether pairing will help them. Often they decide it doesn’t.
For the record the research I mentioned was reported in: Arisholm, Gallis, Dybå, & Sjøberg. (Feb., 2007). Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise. IEEE Transactions on Software Engineering, 33(2), 65-86.