Pair Programming Simplified

In this post, I’m going to cover a quick definition of pair programming, share a few different styles of pairing, then give you an overview of the benefits, challenges and drawbacks of adopting pair programming.  Plus, I’ll highlight some remote pair programming tools which we’ve found useful while pairing at Codurance.

What is pair programming?

Pairing, according to the Cambridge Dictionary is:

Two people or things that have been put together in a pair, or the act of putting two people or things together into a pair. Applying it to software development, it means - Two people working together, as a team, to accomplish the said goal.

Pairing is one of the eXtreme Programming (XP) practices formulated by the well-known software development guru, Kent Beck, way back in the late 1990s. Until now pairing and other XP practices have been applied time and again to various projects, ranging from simple to complex, small to big, in a variety of domains, resulting in amazing and successful implementations.

But how can it be true?? Why would I let two people do the job for one. If I have to do two tasks, then it will take double the time and twice the resources!!! One writes code, while the other watches over!!! Why? Seems like madness!!!  ........ Or does it?

For this, we have to go back to our understanding of ‘cost'. If we take a long-term view, what does ‘cost’ mean, in terms of money and time? No matter how complex the problem is, would it always take twice the time to develop a couple of tasks if two people are working on it? And what about quality? The following paragraphs will unveil the method to this 'madness'.

Until then, something to take on faith - Some quote from the industry greats:

Jean Bartik (One of the ENIAC women, who are considered by many to be the very first programmers.)

Kent Beck

Different styles of pair programming

Let us start with 'how do you do a pairing session'?

There are different styles of pair programming. Each of these pairing styles has its advantages and disadvantages. You should choose the style that suits you the best and for the task at hand.

• Driver and Navigator: The Driver is the person in control of the keyboard/mouse (i.e., the steering wheel). They should always talk aloud and communicate continuously what they are doing while doing it. The Navigator has a much more passive role (i.e., reading the map), as compared to the driver. They review the code and share their thoughts about it, while the driver is at work. The navigator keeps track of the larger goal and potential bugs, following best practices and making notes of potential next steps or obstacles. Driver-Navigator works quite well with two experts, who may trade roles at regular intervals.

• Strong-Style pairing/ Backseat Navigator:  The golden rule:

"For an idea to go from your head into the computer, it MUST go through someone else's hands".

In this style, the Navigator is usually the person much more experienced with the setup or task at hand, while the Driver is a novice (related to language/tool/domain/codebase/etc...). The experienced person mostly stays in the Navigator role and guides the novice. While this technique borders on the do-as-I-say approach, it can be a useful onboarding tool. It engages the novice to "learn by doing" over the more passive "learn by watching" style.

• Tour Guide: As in Strong-Style/ Backseat Navigator, here too, the Tour Guide style works best with an expert-novice combination, particularly in cases of a brand new novice. The Driver (expert) does the strategic thinking. The difference is, in this style the Driver also does the typing.  As they do this, they continuously inform the “tourist” (novice) about what they are doing. Just like a Tour guide explains the various sights to the tourist. The tourist rarely intervenes or challenges. The discussion regarding the implementation is to be done after the test is complete. This style of pairing has the risk of the novice (tourist) shutting off after some time, but oblivious to this, the driver (Tour guide) continues on.

• Ping Pong: Most find this the most interesting one and probably that is the reason it is also the more commonly adopted style.  This style has a strikingly differentiating factor from the rest. This technique wholeheartedly accepts Test Driven Development (TDD) and is perfect when you have a well-defined task that can be implemented in a test-driven way.

"Ping": Developer 1 writes just enough code for a single test to fail.

• Remote Pairing/Distributed Pairing: In an increasingly distributed world, it is not uncommon to be in a distributed team, or have some team members occasionally/permanently work from home. You can still practice pair programming, as long as both of you have a reasonably stable internet connection.

Benefits of pair programming

Pair programming has innumerable benefits. Some of them are listed below:

• Fewer bugs and mistakes: When software developers work alone, there can be several subjective nuances that the code will be subjected to. This could be as simple as misinterpreting the requirements or rigidly sticking to a favoured design pattern. With pair programming, the pair can exchange ideas and understanding to eliminate this issue.  Pair programming allows the navigator to keep a more abstract context in mind and think of all the use cases the implementation should satisfy, while the driver is implementing it. It allows parallel activity of implementation and planning. This helps in reducing bugs, mistakes and reduces common pitfalls uncovered during testing.

• Better quality and speed: Pair programming enables instant feedback where the second developer can challenge or correct the first. This allows for a great opportunity to bounce ideas off each other and optimise from the outset. Thus improving the quality of the implementation. In most software organisations, there will be a task for 'Code Review' in the software development process flow. Pair programming enhances this process flow as the code is constantly reviewed as it is written. Faster feedback leads to faster development time.

• Accountability: When working alone, there is always a chance that, due to deadline pressures or fatigue, some issues could be swept under the carpet and thereby accumulate technical debt. There could also be cases where developers could employ certain shortcuts or hacks to get the implementation done. Pair programming brings in accountability for any code that is written. Developers should pride themselves on their code and pair programming brings in confidence as well.

• Knowledge sharing: One of the most important enablers for a team to be fast is the breadth of knowledge the team has. Breadth of knowledge enables any team member to jump into any part of the code to develop, fix or refactor it.

This means knowledge sharing should be an on-going process. It should be done on-the-job. 

Pair programming provides the opportunity for on-going knowledge sharing. When pair programming, more than one person would know the exact reason why the code was written in the way it was written, what was involved in making the design decisions, and also the hurdles faced and the remedy applied. It also removes the bottleneck of only one person having knowledge of any part of the code and reduces dependencies.

• Faster training: The partners in pair programming are usually two mid-level/senior developers, or a combination of new joiners and senior developers. This provides the perfect setting for on-the-job training. The new joiner or the less experienced can use the pair-programming session to quickly learn the domain, coding practices and maybe also some tricks-of-the-trade; improving team morale and collaboration.

Common challenges during pair programming

One of the biggest arguments against introducing pairing to your team's arsenal is the risk of some members dominating the exercise and in the end losing the collaborative essence of the routine.

This might be especially prominent given that your team members were mostly used to working in isolation all of their careers and are simply not used to sharing the development process with anyone else along the way.

There are some measures that you can take in order to minimise that over-dominant aspect of one of the pairing partners:

• Align on the shift of leading before you start: Not doing so is actually a basic mistake when it comes to effective pairing sessions in general.

This will always allow for the less-dominant pairing partner to take the steering wheel on a regular basis.

Ideally, switch every two hours regardless of the progress and codebase state.

• Branch out: If the other person is leading towards his solution without considering much your feedback, propose that you do it in a separate branch.

Eventually, some of the solutions will not be working out. At this point, you can quickly revert and naturally move into trying your solution.

Thanks to that you will avoid any unnecessary quarrels at the start.

• Team Lead moderation: Bring in your team lead or one of the senior engineers to the pairing session to act as a moderator.

We should be careful though not to make this a standard practice or constant necessity.

A handful of sessions at most should be enough to straighten the dynamic within the pair.

Drawbacks to pair programming (and how to overcome them)

Let us look at some of the drawbacks, or cons of pair programming.

• Cost: There is this (illusionary) glaring cost aspect of pair-programming which is hard to ignore for the uninitiated.

• Follow the master: This is one of the risks in the Driver-Navigator type of pair programming.

• Over-complicate simple tasks: In situations where the task at hand is a trivial and straightforward one, there is a risk that pairing for such a task can make it unnecessarily complicated.

• Personality conflicts: There is always a human element where there is teamwork. The motive of pair-programming is to improve productivity amongst other things.

• It is hard: Adopting pair-programming is always hard at first. Anything new is hard and pair programming is no different. The thought of doing pair programming all day, every day, is too overwhelming to make a start. So it is a good idea to start small. Productivity is the key. Pairing for shorter durations, incorporating frequent breaks and changing pairs provides much variation and helps maintain focus.

Remote Pair Programming tools

With the pandemic a lot has changed in the software industry and that applies to the team distribution and structure as well. It is not uncommon that people in the same team are distributed across towns, cities, countries and even continents. So we can say, pair programming can be in some cases "remote pair programming" i.e. Pair programming done by two or more developers who aren't in the same physical location. Hence, now it has to be usually carried out via a screen share or IDE sharing tool.

To cater for this need, we have seen a number of remote  pair programming tools that have entered the market. Each tool in this list falls into at least one of the following categories:

Collaborative IDE: In this category, the tool lets the users invite other programmers to collaborate directly in their IDE. Only the IDE is shared in this category.

Single user sharing, dual/multiple user control: In this category, we have tools that allow a single user to share their screen while other users can view and control the screen. So a single user shares their screen at a time. However, both the sharer and the viewers can control the device at the same time.

Multi-user sharing, multi-user control: In this category, we have tools where multiple users can share their screens and control at the same time. This category offers the highest level of interactivity.

• Category: Collaborative IDE

• Category: Single user sharing, multiple user remote control

• Category: Multi-user sharing, editing and multiple user remote control.

CoScreen
CoScreen is a great tool that the engineering teams can use to share their screens, edit and work on the code together. This tool offers multi-user screen sharing.

Another standout feature of CoScreen is that it lets the users select a specific application window to share. i.e. Users can share a window, unshare it, and share another window seamlessly all in a single click during a collaboration session.

CoScreen is supported for Windows and macOS.

Other noteworthy tools are:

• CodeSandbox Live
• Codeanywhere
• CodeTogether
• CodePen
• MotePair by Atom
• Teletype for Atom

Conclusion

You can love it or hate it, pair programming remains a time tested process, which when done right, produces good quality code and enhances productivity. It is hard, but it is certainly worth it. It is as with the view from the top of Everest - it is phenomenal, but the good thing of pair programming is, it not as hard as scaling Everest. But provides the same sublime bliss as the view from Everest peak. Give it a try and enjoy… :)

Some of the pair programming environments mentioned here may have costs and fees attached to them.