In software development, working solo might not always turn as the best solution. This has especially become a fact in the case of a bigger project. Pair programming, which is an agile development technique, produces good results and strengthens the team spirit. In pair programming, two programmers work together at a single workstation. Each of them plays a single role, one as the Driver who writes code and the other one as Observer or Navigator who reviews each code line. They switch roles frequently.

Furthermore, the programmers don’t need to reinvent the wheel. Pair programming is all about improving in the process by collaborating and innovating, which in turn helps to reduce the errors. This happens due to continuous reviewing that come up with improvement ideas and prevent future errors. As a result, the driver can focus on the tactical aspects of completing the coding while using the observer as a guide and safety net.

Though pair programming is not suitable in every situation; however, wherever applicable, it gives a lot of fun and the scope of knowledge sharing and motivation.

How to perform Pair programming

There are multiple aspects of pair programming.

1.     Different Styles of Pairing

Driver and Navigator

This is the classic style of pair programming where two programmers play key roles – Driver and Navigator. The Driver is the person who is the main coder and at the wheel, which is where the keyboard. The Driver is focused on finishing the goal at hand, ignoring the bigger issues for the moment. On the other hand, the Navigator plays the role of observer and reviews the code on-the-go. He is the person who shares thoughts and gives direction. Besides, he is responsible for keeping an eye on the larger issues and bugs. He makes the notes of the next steps and identifies the obstacles.

Why is this division of roles in pair programming? Well, there are two approaches to thinking here. The driver thinks tactically, where his focus is more on the details, at the lines of codes, whereas the navigator thinks more strategically as an observer. He should have a bigger picture in his mind.

The flow goes like this:

– It starts with a well-defined task

– The programmers agree on one tiny goal at a time. This is defined by a unit test, or by a commit message, or based on a sticky note.

– The programmers switch roles regularly and keyboard. This keeps their energy level up and allows them to learn and understand things better.

Ping Pong technique

This pair of programming technique is based on Test-Driven Development (TDD). However, it is perfect if you have a clearly defined task suitable to implement in a test-driven way. How do things work in this case? Consider two developers are working in this mode, Developer A and Developer B. Then the steps are executed like this: 

– Developer A writes a failing test which is called “Ping”

– Developer B writes the implementation to make it pass which is called “Pong”

– Again, Developer B starts the next “Ping”, i.e. the next failing test and the steps go like that.

– Each “Pong” also follows the code’s refactoring together before it goes to the next failing test. This is known as the “Red-Green-Refactor” approach. Here developers write a failing test indicated as red, make it pass with the minimum necessary means, i.e., green, and then refactor.

Strong-Style Pairing

This technique is beneficial for knowledge transfer. It works on some rules like, as mentioned by Llewellyn, “For an idea to go from your head into the computer, it MUST go through someone else’s hands.” In this style, the driver is a novice in language, codebase, tool, etc., whereas a navigator is an experienced person who guides the driver. Here the driver totally relies on the navigator and must be “comfortable with incomplete understanding.” This type of pair programming is much more effective.

Apparently, this technique seems like micro-management. However, it acts as a useful onboarding tool that stresses the “learning by doing” instead of passive “learning by watching” method. So, this technique is ideal for initial knowledge transfer. However, the goal is to easily switch roles after some time to eliminate the micromanagement mode. This indirectly indicates that the knowledge transfer worked.

2.     Rotations of Pairs

Pair rotations are an effective part of pair programming where after working together for some time, one half of the pair leaves the pairing, and another person is onboarded to continue the process. One aspect of this rotation is the logistical support of the pair programming. It is possible that any of the pairing persons could be on leave or working remotely for a time, but the work requires the role’s physical presence.

Another aspect of rotation is to mix things up. It is possible that after working together for a while, one of the persons starts showing the signs of “cabin fever” due to spending too much time together. Also, the work may be very tedious and energy-draining. Hence, a rotation gives one of the persons a break. Simultaneously, the new onboarded person can bring in some energy and fresh perspectives in the scene.

Finally, pair rotations’ most obvious reason is to increase collective code ownership, avoid knowledge silos, and more code review on the go. This increases the average number of eyes for code review.

Now, when it comes to the question of frequency of rotations, the opinions diverge often. Some specify that the rotation must happen every 2-3 days. However, there are few things to consider for a rotation. For example, onboarding a new person and switching the context come with some cost. Furthermore, if there is no guarantee of one person’s continuity, then it is an overhead risk related to tactic knowledge. This enhances the chance of rework.

3.   Physical Setup of Pair programming

Physical setup plays a crucial role in Pair programming as the programmers work closely together, sharing the physical space. It is quite different from the scenario where you own a solo workstation. Instead, here you need to share the keyboard and workstation. No doubt, this needs a certain level of attention and respect for each other. Not only that, but it is also worth spending some time to figure out a comfortable setup. This needs enough space for programmers.

However, either the programmers can share the keyboard and mouse or use a separate keyboard and mouse for each of them. It depends on the situation and space. Similarly, screen sharing also matters here. Either two monitors or shared monitors can be used.

4.    Remote Pair programming

It is possible that a project is being executed in a distributed pattern where team members are often placed in a remote location. Even it is possible that some team members occasionally work from home. Does that mean pair programming is impossible in this case? Well, it is possible as long as both the programmers have a stable internet connection. The most important aspect here is both the programmers must have a screen sharing solution so that they can see the screen and control each other’s machine. Many video conferencing tools are available in the market for this purpose, both licensed and open-source.

Not only the screen sharing option, both the programmers must be able to see each other through the video call. Also, collaborative online visualization tools must be in place to share the experience through sketches if needed for planning and designing. At the same time, the audio experience must be good.

Pair programming benefits

Scope of Knowledge Sharing

This is the obvious benefit of pair programming. Since two people work on a piece of the code, that helps spread knowledge and prevents silos of knowledge. This applies to both technology and domain and daily. Moreover, when two minds discuss a problem, it improves the chances of finding a good solution. Different experiences and perspectives bring on more alternatives.

Reflection

Pair programming removes the constraint of solo thinking and forces programmers to discuss solutions and approaches. This reveals whether they have a correct understanding of the technical aspects and can provide a perfect solution or not. This is equally applicable to the user stories.

Prevents errors by Keeping focus

Pair programming often prevents errors in the code and helps programmers to find a structured approach. Since the two programmers can explicitly communicate with each other, they can retrospect what they are doing and why. It prevents programmers from getting distracted from their tasks. As a result, it reduces or even eliminates errors in the code.

Code review on-the-go

Pair programming gives you enough chances to improve the code. Because when it is a pairing, it has 4 eyes that notice the little and the bigger things on the go. Hence, it easily catches more errors on the go; instead, the entire coding is finished. No doubt, performing code review at the end has some downsides.

Combined thought process

As mentioned in the classic driver/navigator style of pair programming, it allows us to bring a different perspective on the code. Here both tactical and strategic views work at the same time. This combination increases the code quality as it allows the programmers to pay attention to the details keeping the bigger picture in mind.

Keeps the team’s Work In Progress possibility low

One of Kanban’s core principles is limiting work in progress, which helps to improve team flow. This, in turn, also helps the team to focus on the most important tasks. Therefore, if there has a WIP limit in place, it enhances overall team productivity. Pair programming limits multitasking in a team, especially in larger teams. This prevents them from working in parallel. Consequently, it increases the overall focus. This ensures a constant workflow.

Fast on-boarding of new team members

Since pairing and rotation of pairing facilitate knowledge sharing, it helps with the onboarding of new team members fast. In solo working mode, it takes time for new onboarded members to understand the project and work. On the contrary, pair programming minimizes this impact as it forces team members to communicate a lot as part of their task.

Pair programming disadvantages

Pair programming has many advantages, as we have discussed in the previous section. However, the success of pair programming is very much dependent on the approaches of the programmers. Here are some of the cons that are inherent in pair programming.

– In the pair programming process, both programmers have to be actively engaged with the task throughout the paired session. Otherwise, there is no benefit of this mode of working.

Pairing must be done efficiently; otherwise, it can double the cost in the worst case.

To get the process’s maximum outcome, the programming model should be “programming out loud.” Hence, if the driver is silent, the navigator must intervene

– Pair programming cannot be fruitful if there are relationship issues between the programmers. So, this should be solved before pairing.

– Pair programming must not turn into a micromanagement mode. Otherwise, it will become a frustrating experience for one of the programmers.

– Navigator must also respect the thought process of the driver. For example, if the navigator notices something wrong in the driver’s coding, he must not immediately interrupt; instead, he must wait at least 5 seconds before uttering anything. It is possible that the driver might already have it in his mind and will correct it. Needless interruption can cause distraction in the thinking process of the driver.

– Sometimes, keyboard hogging becomes an awkward issue for the programmers. This turns into an annoying experience and also creates a hard time in active participation.

– Pairing for 8 hours a day could be exhausting. During pairing, programmers must remember that they have alternate tasks other than coding, like email checking.

– Intense collaboration can become impossible because it needs working closely with another person for long stretches of time. Here it would be best if you had constant communication with empathy. Hence, it needs great interpersonal skills.

Due to the above reasons, pair programming is bad at times.

Final verdict

Pair programming as a whole is all about embracing the change. Agile development principles acknowledge that change is inevitable. So, the team must be prepared for it. As it has advantages, at the same time, pair programming has some limitations. It often creates friction and also an intensive process. Moreover, ego problems between the programmers can be dangerous to the task at hand. However, we can give it a chance if we consciously treat it. If it is taken as a scope of improvable skills and a better chance of programming, we will definitely end up with a more resilient team.