Pair Programming —Beneficial or Not?

source — Guido Gloor Modjib in Flickr

Pair programming is a software development technique in which two programmers work together on the same task at the same workstation. This technique has become increasingly popular in recent years, as it has been shown to have several benefits, such as improved code quality, increased productivity, and better communication between team members.

I was a true believer in pair programming. I started my career learning these best practices and embedded them with Agile. Extreme Programming, Clean Code, and Refactoring were some of those terms I, as a fresher, was very fond of. We all were taught some of those pairing etiquette.

1. It would be best to make changes with your pair.
2. You must rotate the coding cycle with your pair.
3. If your pair has not agreed, you must resolve it before proceeding. Consent is important.
4. And mainly, it is all about one driver and one navigator.

Indeed, during my initial years, these etiquettes not only taught me but also groomed me well. It was easy to get onboarded, understand best coding practices without specific sessions, and have some fun time between pairings.

It all seemed great until you came to the other side of the table and evaluated whether the pairing was adequate for your business. It depends on what you are trying to solve and with whom. The pairing has its challenges,

1. It can be mentally exhausting.
   Working with another person for an extended period can be draining, especially if the two individuals have different working styles or personalities. This can lead to burnout, negatively impacting productivity and overall morale.
   I came across a pairing model called Silent Pairing. In my opinion, the founder of this model was frustrated and forced into pair programming. You work on the problem statement without uttering a word. It is exhausting for both.
2. It can be time-consuming.
   While the technique has been shown to improve code quality and reduce the number of bugs, it can take longer to complete a task than if one person were working on it alone. This can frustrate some team members, especially with tight deadlines or other time constraints.
3. Challenging for Individual Contributors.
   Some programmers may feel that they are more productive when they can work independently without the distractions or interruptions of another person. This can lead to tension between team members and may even cause some individuals to leave the team or the company.
   For example, if you put a staff engineer on a regular pair programming model, I wonder whether we will do justice to that role.
4. It can be challenging in certain situations.
   For example, if team members are working remotely, it may be challenging to collaborate effectively using this technique. Similarly, coordinating pair programming sessions may be challenging if team members have different schedules or work in different time zones.
   I faced this challenge, especially during COVID. In one of the organisations I was part of, we experienced rapid growth during that phase, and we had to pair with individuals to ramp them up quickly. Even though we had good intentions and wanted them to start contributing to the product, it was challenging and frustrating to deal with the remote pairing setup and other associated factors.

I later found that promoting these techniques can significantly increase your revenue, especially when you are on the consultancy side. Adding 10 developers to run 5 streams of work, and let's say you are charging $40/hour (assume), clearly a $3200 of total revenue is excellent (I haven't accommodated the cost for PM / Tech Lead / Principal Engineer) which you as a business may achieve in ~40% less cost if you move to Pragmatic Pairing, and ask the right question, whether we need active pairing. A few alternatives could be,

1. Knowledge Sharing?
   Way to tackle — I will conduct an internal demo within the team at the end of every sprint or desk check after dev completion, whichever works best for the team. But the strategy has to be in our Definition of Done.
2. Thinking loud?
   Way to tackle — I can be as loud as I can ;). Just kidding. In recent years, instant messaging apps have become our go-to tools for asynchronous team communications. If I am stuck and my team's wiki isn't helping, I am just a step away from posting my query to the team's private channel or asking someone directly. Why do I need to keep someone busy with me the whole day? I want to think aloud. Didn't I do the same during my interview? Hmmmmm.
3. Continuous Code Review?
   Continuous code review is an antipattern rather than a benefit here. I would raise frequent and short PRs and share them with the entire team rather than only seeking feedback from one person. We write software based on our assumptions, not what we actually think.

We can consider many alternatives before opting for pair programming. Especially as a business, when we hire an agency to build products for us, and if they insist on pairing because it's the best practice to follow, it can just be their business model to generate revenue. It's not wrong, but consider whether it benefits your business.

In conclusion, while pair programming can be an effective technique for improving code quality and easy-to-share context, it is crucial to consider the potential side effects before implementing it on a team. By being aware of these side effects and addressing them, teams can ensure that they use this technique most effectively, not forcefully or blindly. Each programmer is uniquely talented, and forcing them to follow pairing all the time wastes their capability to build something big.