Pair programming is a widely used agile software development technique and its principle is quite simple: two developers work together on the same codebase by sharing a screen and a keyboard, whether physically in the same room or connected online.
The benefits of pair programming are quite obvious and well known to the many who have been practicing it but it might be worth quickly summarizing for those still unsure:
- Code quality increase: having to explain an implementation solution to a colleague or being challenged on a decision, forces you to think about it more carefully, avoiding pitfalls and rushing into something which might reveal itself as sub-ideal in the future. Code standards and maintainability also become a natural result of this.
- Sharing knowledge across the team (on both the codebase and the requirements) makes it easier for different team members to pick up various pieces of work and become familiar with different parts of the software.
- Technical skill levels increase as developers with fewer skills in certain areas learn faster and hands-on from more skillful colleagues.
- Reduce the need for code reviews, which, especially for complex code changes, could be difficult to understand when not particularly familiar with certain parts of the code.
- Pairing can also be used to encourage collaboration across different teams and projects: if you have to modify the code of a project another team owns, this might become a daunting experience when done alone. On the other hand, sitting together with a member of the other team can make this a whole lot easier and, at the same time, ensure the code standards are guaranteed. On the plus side you might also get to know people outside your team.
The pair programming approach varies a lot in the software development industry: in many companies this is not even considered, whereas others religiously follow it and require developers to pair for the entirety of their development time. Both these options seem fairly unreasonable to me and a healthy compromise should be implemented in order to guarantee the developers’ sanity, productivity and code quality.
As pretty much every aspect of agile software development, pair programming should not have rules set in stone. It is important to take a pragmatic approach and the points below provide an idea about how to address some of the issues you might have faced in your work environment:
- Tiring: pairing can feel like a very tiresome exercise at times, it usually requires more engagement than developing alone as you constantly have to explain and articulate your thoughts, possibly being challenged by your colleague. It should therefore be completely fine to take a break from time to time, we are not robots in the end!
- People often just want to get on with their jobs: a lot of software developers seem to be leaning towards an introvert type of personality and might be more inclined to put their heads down and work alone, not to mention pairing is sometimes perceived by some developers as taking the fun out of coding! Avoiding pairing on certain tasks should be totally acceptable but it is also important to recognise when a bit of code or a task is particularly crucial and best done as a pair.
- Resistance / challenges from business: Pairing can sometimes be perceived as a waste of time / resources. “Why should a team get two people to work on a task when the same could be done by one” is an argument you might have heard by people who don’t see this practise favourably. The reality is pairing typically results in an increase of the overall team velocity. As for different aspects of software development (e.g, technical debt) some teams might have a hard time justifying how they spend their time and risk being micromanaged. In companies where pair programming is not used, it should be easy to spot cases when work gets blocked because it can only be performed by one person and this can be a case in point for trialling pairing.
- Ease of mind giving feedback when pairing: people work at different speeds, have different personalities, different skillsets and use different approaches: this is perfectly fine and everybody should feel comfortable enough to ask a peer to slow down, explain something more than once or challenge a solution. Ultimately, the important factors are what the team produces and the delivery timeframe.
- Do it when it makes sense! Simple, boring or repetitive tasks are definitely not good candidates for pairing as it won’t provide a great deal of benefit and might alienate / frustrate two people of instead of one. Pair when it makes sense and be pragmatic about it.
- Don’t delay pairing on a task until it’s too late: if you get started alone on something and the task grows out of proportion gradually, you might feel the urge to try and finish it by yourself, possibly ending up in a spiral of complexity and isolating yourself and your work from the rest of the team. Recognise the task is more complex than you originally anticipated, stop, take a step back, and pull in someone else by doing a bit of pairing. Even just walking another person through what you did can help you clear your mind and discover a better path.
- Whether your company is geographically distributed or people wish to work from home, remote working is rapidly growing and can sometimes be perceived as an obstacle for pairing. I was myself under the impression it would be difficult or somehow more challenging to pair remotely until I worked for a remote-first company. A simple screen sharing tool is often all you need to pair remotely and if the company culture truly embraces this, it shouldn’t make any difference if you are sitting in the same room or having a video conference. Some tools such asfloobitsshould also allow you to integrate pairing with your favourite IDE.
And so these are my two cents about pair programming, happy coding!