Apples and Pairs: Why we advocate pair programming and you should too!
By Sam Bryant
Let’s start off with a bit of myth busting. Pair programming is half as efficient as good engineers working solo, right? Wrong.
Studies that have been carried out on pair programming found that pairs consistently write higher quality code. Not only do they suggest that the code is of higher quality, they suggest that it was also written faster.
They also found that pairs write code containing fewer defects. The savings made by removing these defects “more than offset the development cost increase”.
In our opinion when you start to look at all of the other benefits pair programming provides it becomes a no-brainer.
How do we pair at Ak (Armakuni)?
Rotation, rotation, rotation — we believe that pairs should rotate every half a day to a day.
High-quality pairing stations — each pair should have two keyboards, two mice and two screens mirrored and plenty of space.
Happy pairs — when done right, pair programming is fun and happy engineers do better quality work. If an engineer or a pair isn’t happy we need to work out why and help them.
Why rotate?
Rotating pairs regularly is an extremely important part of the pairing process at Ak. Pairing is a great way to transfer skills and knowledge between individuals. If we rotate regularly that knowledge gets spread across the entire team, not just a single pair. If we are rotating regularly we get to work with every member of the team. We can learn from and draw on all of those skills as we do. We feel that you actually learn just as much, if not more, from pairing with a more junior engineer. A side effect of regular pair rotation and having many team members working on a codebase is that the codebase gets constantly improved. New developers can see new ways to simplify and improve the codebase that might have been missed before.
In one of our previous blog posts, we spoke about SuperHero developers and the SPoFs that they become. If we rotate our pairs regularly then we prevent SPoFs by sharing skills and knowledge across our entire team. Enabling us to build brilliant high-quality and sustainable teams.
Efficiency
At the start of this post, we briefly spoke about how pair programming can cause an increase in development costs. With those costs offset by cutting down on defects, but is it the whole efficiency story? Not even close.
At Armakuni we believe that doing it properly the first time always saves time. Through pairing, we can ensure that code reviews happen at the time of code creation. Not only does that help us cut down on defects, it helps to prevent incurring technical debt. All of these benefits without ever having to wait for a pull request to be reviewed and approved.
By pairing, we ensure that we never need to context switch. As we rotate pairs we ensure that a single member maintains context from the previous pair so work can continue as efficiently as possible. Research tells us that context switching can cost as much as 40% of our productive time, so minimising that cost is really important.
Morale
Happy developers are extremely important to producing high-quality software. One of the studies we mentioned earlier also found that pairing made developers happier and more confident.
Why could that be?
It’s probably due to a number of factors, not least that peer reviews are a continuous process. We completely avoid that sinking feeling of a senior developer reviewing your pull request and suggesting a load of changes. Instead, we get to collaborate with that senior developer as we write our code and make constant micro improvements. The whole experience stops even feeling like a review at all, its just continuous teaching and learning.
Me becomes we; by pairing and rotating, code ownership moves from an individual to a team. Gone are the fears of someone accusing an individual of making a mistake, “we” as a team made a mistake, and “we” as a team will fix it. This enables developers to feel safer and less stressed within their development environments.
Conclusion
Ok, so by now we are all in agreement that pair programming is pretty great. Right?! Happier engineers, shared knowledge and skills across a team, no single points of failure, faster, higher quality deliveries.
Do you need more convincing?!
Ok. If we start thinking about what some of these benefits start providing we are creating an environment that enables XP (Extreme Programming). Why should we care about XP? Through XP we can start looking at continuous deployment. Make a commit to version control to create a feature, push the feature through environments in an automated pipeline and automatically promote the feature to production.
What better way can there be to deliver business value quickly? We believe that pair programming really is a key enabler for continuous deployment. If everything else wasn’t already enough to convince us (it was), then consider us convinced!
