My former colleague Vivek Vaid has an interesting post about parallel-paired programming where he talks about introducing lean concepts into deciding when we should pair to get maximum productivity.

Midway through the post he mentions that the original reason that we starting pairing was for ‘collaborative design’ which got me thinking whether there are reasons beyond this why we would want to pair.

I have often worked on clients where the value of pair programming has been questioned and it has been suggested that we should only adhere to this practice for tasks where it adds most value.

Clearly collaborative design is one of these, but there are some others too:

Faster Onboarding

The idea here is that someone who has been on the project for a great amount of time (possibly the Tech Lead) can help bring newer members of the team up to speed.

They can help the new team member to get their development environment up and running (although clearly making this as automated as possible is beneficial!) and help walk them through the code covering any questions they may have.

This role may also involve going though the reason that the team is there (i.e. what problem we are trying to solve), an overview of the way the problem is being solved and the technologies being used to do so, patterns being used in the code and any other information that is considered useful to the new team member.

Using pairing in this context makes it much easier to get new team members up to speed, therefore improving their ability to be a productive part of the team.

Increasing Team Level

Pairing up senior and more junior members of a team is a very effective way to increase the level of the junior person.

More senior team members have a lot of knowledge which they can pass onto junior team members – as this knowledge comes from experience in the field it is not necessarily something that could be gained from reading a book.

On several of the projects I have worked on one of the more Senior members of the team has been the one who provided the onboarding for new team members.

Clearly there needs to be a balance with this approach because no matter how patient the senior person is, at some stage they are going to want to have the opportunity to work with someone closer to their level of ability.

Using pairing in this way helps to bring up the level of the less experienced members of the team and allows them to learn things that more senior members of the team probably take for granted.

Knowledge Sharing

This one is a harder one to sell because there are no doubt other ways of sharing knowledge on teams beyond just pairing.

However, I have seen it work successfully on projects I have worked on for spreading the knowledge of how different parts of the application work amongst the team. This is generally referred to as increasing the truck factor – no one member of the team should be invaluable.

I saw this as a benefit on a project I once worked on where I had spent the majority of our time pairing both with ThoughtWorks colleagues and client developers.

At the end of the project we had a meeting to discuss what handover needed to be done in order to allow the team to continue when we finished. We really struggled to find anything at all – the knowledge of how to do the vast majority of tasks was completely spread out amongst the team and no one person had knowledge that the rest of the team didn’t have.

This is almost like a side effect of pair programming but it definitely has some gains which should not be discounted.

Pair Programming vs Parallel Pair Programming

I’ve never used parallel pair programming, only pair programming which is used the majority of the time on projects I have worked on.

I would be interested in knowing whether we can still gain some of these other benefits from using parallel pair programming – it seems to me to be quite a streamlined version of pair programming, and I wonder whether we would still get the useful side effects of pairing if we don’t pair all the time?

Mark – You are spot on target with all the benefits. The simplest principle I have is to use “conscious” pairing vs. “unconscious” pairing. A pair should always *know* why they are pairing.

Alfino Batolo

“Developers and testers both do essential but complementary jobs. TDD tries to make developers think in a way that is not natural for them. I always thought XP would be a better practice if pair programming would’ve asked for a developer to be paired with a tester all the time!”

Mark,
Great article. My team is utliizng pair programming for these purposes. I also think that the ideas above will help make a great case for thos managers and leads that want to add pair programming nito their teams. Well done.