Sep 1, 2019

Pair Programming - What, how and why?

What is Pair Programming?

Pair programming, or ‘Pairing’, is a software delivery / development practice where a team decides to have two engineers collaborating on any work in progress whenever possible. The intention is to help a team share context, produce higher quality code and accelerate productivity, which is probably why Pair Programming is very commonly used by agile teams. As the old indium goes, Two heads are better than one.

How to Pair Program?

Pairing isn’t exactly rocket science however there are certainly better ways to do it than others. Here are some tips / pointers I’ve picked up in my time:

Pairing works best when both people are actively contributing.

The general idea is to have the two people in the pair performing complementary collaborative roles, ‘driving’ and ’navigating’. The driver is the person actively typing on the keyboard and implementing the solution and the navigator is setting a higher level direction and thinking about where the code will go next.

While performing these roles the pair should be engaging in a consistent dialogue asking for opinions, clarifications of intent and talking about the requirements of the task at hand. It is important for the two to swap roles from time to time so that they both get a chance to set the higher level direction as well as write code.

The people in the pair must have a mutual understanding of how they will work together.

I prefer a very informal, ad hoc style of Pair Programming where the person I’m pairing with and I feel comfortable to swap roles very frequently without the need for explicit procedure. This is far from the only way to Pair Program though.

Adopting a structured approach to a pairing dynamic can be very helpful especially when a team has members who are new to pairing or if there are behaviours between team members which lead to one person taking over. Two commonly used structured pairing strategies are:

Fix time pairing:

The pair take it in turns being driver navigator for fixed periods of time and swap at the end of that period. This works well although can be disrupted very easily by day to day occurrences like meetings. I’d keep the rotation period fairly short maybe 30 minutes maximum.

Ping pong pairing:

This style of paring involves TDD and gets the driver and navigator to swap every time the pair writes a new failing test. As they are following TDD, starting each new code change with a failing test, the pair should swap roles fairly frequently.

If you have a new team, even if they are familiar with working in a Pair Programming style it can be useful to adopt a more structured approach until the team matures into consistent ways of working.

Common pairing pitfalls:

Make sure pairs are actually pairing!

When introducing pairing to a team, it is very common for one member of a pair to completely take over the workstation and direction of work. This problem can be exasperated when one of the people collaborating is less confident or comfortable, maybe they are new to the team or code base or maybe they are much more junior, there can be many reasons! Unbalanced pairs where one person has taken charge goes against the entire point of collaborative work.

Having unbalanced pairs can actually be a useful tool if used intentionally. When on-boarding new teammates pairing with them as a driver is a great way to help them find their feet in a code base. Having an imbalance in who drives and navigates can be helpful but it should be done deliberately!

‘Pairing’ individually:

It’s also possible for the two pairs to go off in two totally unrelated tangents. If a pair are using more than one computer at once they probably aren’t collaborating. Again, there can be many reasons for this and the most common one I’ve come across is due to both pairs being new to the practice. It is surprisingly difficult to swap from working day in day out in isolation, like a lot of developers do, to collaborating for long periods of time.

Opposition to pairing:

Occasionally you may find people who just don’t want to Pair Program. This is understandable, I want to reiterate that it is a big shift from the ’traditional’ way of working as a software developer. If a team member isn’t onboard empathy is a good way to bridge the gap.

Be explicitly open that you’re happy to collaborate with everyone in the team. Try starting to introduce more collaboration in smaller, less committed ways, maybe try shared facilitation of meetings, initially and to help ease the transition of consistently collaborating. Take a look at other techniques such as Mobbing to help introduce a team to coding collaboratively together.

Changing the whole world at once…

Pairing can be quite tiring especially initially if you and your team are not used to collaborating for long periods of time. It can be useful to have reserved time for pairing and also some time set aside for looking at things individually, self learning, checking email and other non programming tasks. Establish some core pairing hours that work for your team and try to avoid meetings in those hours. Pairing is a behavioural change, you’re trying to form a new habit and that doesn’t happen immediately.

Not Rotating Pairs Frequently:

One of the main drivers for using pair programming is to help propagate knowledge inside a team. To that end it is imperative that a team swaps members of pairs frequently so that knowledge is spread broadly as well as quickly. I generally suggest a paring rotation frequency of once every two to three days.

It is a good idea for one of the members of the pair to remain on the same piece of work to carry across the context of what has been done so far, this is commonly referred to as ‘anchoring’. A story anchor should start the new pairing session by recapping what the current story is and how the previous pair had approached the problem so far. Then the pair go back to alternating between the driver and navigator roles.

I’ve been in a team which had embraced pair programming but only wanted to swap pairing members every fortnight. This particular team was worried that sharing context with a new pair for the story in progress would take so long that it would be time to swap again by the time they finished.

What this fear created is slightly reduced the risk of knowledge silos, now two people instead of one knows about what they worked on and can answer questions about it however the rest of the team can not. Inevitably this eventually came back to bite us when a pair went on holiday and we essentially had to pick up the rest of their story without any idea of the last week’s work.

As an aside, if you user stories are so big that it takes multiple days to share context then that’s definitely a problem it’s out of scope of this blog post however.

Benefits of Pair Programming:

I have yet to find a more effective way of sharing technical and domain knowledge amongst a deliver team than pair programming. Helping new teammates quickly get productive and when trying to break down knowledge silos, where individual team members are the only people who know how or why something works.

Sitting down and working on a code base collaboratively will inevitably involve at least one of the pair learning something new, most of the time both people learn something new!

The dialog between a working pair will constantly be full of questions, why was this decision made? Why did we choose this approach? Are you sure that’s what the story requires? For long term teammates this will be mostly clarifications when on-boarding it might be around more fundamental questions about the domain or technology the team is working with. The pair is self checking it is doing the right thing.

If one member of a pair asks a question the other can’t answer that should start a broader discussion. When they find an answer you now two people on the team now know why! Behold we’ve instilled knowledge into s team hand possibly removed a knowledge silo!

Enabling new joiners to get up to speed quickly and helping to spread domain and contextual knowledge in a team are very valuable to a delivery team.

Keeping more distant teammates in touch.

It can be very hard to get team leads to pair program effectively if they have a large commitment to other kinds of work, product meetings, steak-holder management etc. However it is definitely worth the effort and maybe reserving some time for a technical lead to pair with the members of a team. It is a great way to share the broader knowledge a more senior developer has and also allows them to remain in contact with the code base in a productive manner.

Higher quality code:

There are studies which claim to show a trend between pair programming and code quality but after skimming a few I’m not sure there is a good empirical way to message code quality improvement. One paper claimed having more comments equates to higher quality and I disagree with this being an accurate metric so instead I’m going to speak to my experience.

Why do I think pairing produces higher quality code? After a while it feels intuitive, having two people thinking about a problem results in less missed edge cases, more well reasoned engineering decisions (they have to be agreed to by the pair). I also have someone how is able to quickly sanity check for typos or silly syntactical errors while I’m focusing on building the functionality of the code.

There is a coding technique called rubber duck programming where a developer explains what they are doing to a rubber duck, or a similar stand-in. Now this is half in jest and half because saying what you’re about to do out-loud can make you realise it isn’t really that good of an idea… Pair Programming is like that but better because you have a real person.

The end of code review?

With two people getting eyes on all new work code reviews become redundant very quickly. Certainly code reviews stop being the primary way of sharing context. If two developers in the team have already looked at the code, they both wrote it what point does forcing a third to proofread it have?

When pairing code review happens in real-time, as the code is being written. While pairing doesn’t make a team immune to defects or mistakes it will catch those that going through a git commit history / pull request would have caught. Pairing also allows for the ‘review’ to be done with the full context of why decisions were made because the pair was present when the code was written.

Learning / Specialists

Related to knowledge sharing with a more specific intent. If there is someone on the team who is an expert in a particular area, machine learning or dev-ops then making an intentional effort to pair that individual with many team members can be a great strategy for increasing the team’s capabilities in that area. This can be tricky though as you don’t want the specialist to repeatedly have to go over the basics every day only to swap pairs the next day and be back to square zero.

Prolonging ‘Living’ Knowledge

Pairing has one other advantage I’ve not talked about yet. It helps maintain a sense of direction in unstable teams. I like to think of teams in a similar sense to the Ship of Theseus, that is when a member of a team changes it becomes a new team, responsibilities shift and dynamics change. Pairing helps reduce the disruption that losing a long standing team member has on a team.

I think teams have a sort of active working knowledge or living knowledge comprised of all the things each team member retains in their head, when a team member leaves some of this knowledge will be lost which can really hurt a team. In a team which has been pairing well most that individuals domain and technical knowledge will have been passed onto the team. Its invaluable if you have a team or company culture where people can jump between projects frequently.

Costs / trade offs of Pair Programming

Should you try Pair Programming in your team? Well lets look at some of the trade offs / consequences and bare in mind that pairing is my preferred style of working in engineering team so I’m probably very biased! ;-)

The main opposition I hear to pairing is always about velocity. Half as many active workstations will half my velocity right??? Well, the velocity for a pair will be lower than two developers working independently if you measure simply in terms of lines of code written. This is an extremely naive measurement to associate with productivity however. Lines of Code !== Value. Pair Programming will find and prevent more bugs before they appear in production and the sooner bugs are fixed the cheaper. Pair Programming will produce higher quality, well reasoned code.

You can even dip your toe in the water initially if you have reservations. Not all team’s pair program all the time. If a team is very mature then they may find the knowledge and context sharing less valuable and reserve pairing for only new or complex tasks. Personally I prefer pairing by default, I find it reassuring that the team is actively sharing knowledge and collaborating on solutions. As someone who has worked primarily as a consultant for short time-frames in teams Pair Programming has been invaluable to both getting myself to productivity quickly and then helping others who join after me do the same.

To conclude…

For me Pair Programming is a staple of a healthy agile delivery team. It is the most effective way I’ve ever experienced for sharing context and technical knowledge among team members. It helps tackle knowledge silos and single points of failures within a team. The number of defects introduced decreases and code reviews are not necessary anymore.