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.)
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."Pong": Developer 2 writes just enough code of implementation to make it pass.
Developer 2 then continues to write another failing test (Ping) and then hands it over to Developer 1 for the implementation (Pong).. And this continues.
Each "Pong" can also be followed by refactoring the code together before you move on to the next failing test. This way you follow the "Red-Green-Refactor" cycle.
- 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.
For remote pairing, you would need a screen-sharing solution that allows you to at least see, but even better if it allows you to control the other person's machine, so that you are able to switch the keyboard, mark corrections, suggestions, etc. Many video conferencing tools today already support screen sharing like Microsoft Teams, WebEx, etc.. There may also be open source tools for video calls with remote control.
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
Live Share (VS Code)
Live Share is an extension for VS Code and comes included in the latest versions of VS Code. So it is supported for Windows, Linux and macOS. This tool enables developers who use VS Code to collaborate in real time. Live Share also gives the ability for a user who doesn't have VS Code installed, to join a session via a web browser.
Microsoft Visual Studio Live Share is a versatile tool. Everything about this tool is made to be inclusive and customized by the user for their needs. When a user starts a live share session in Visual Studio Visual, their teammates get instant, secure access to the user's code in their own tools. The teammates do not need to clone, copy, or configure it.
Microsoft Visual Studio Live Share allows the user to co-edit, co-debug, have audio calls, chat, share terminals, servers, and even review comments. This is a great way to increase collaboration and drive team cohesion.
Category: Single user sharing, multiple user remote control
Tuple is a Mac-only remote pair programming tool. It has no lag and great user experience.
Tuple is a screen-sharing app with remote control capability for macOS. i.e. One user shares their screen, while other users can view the screen and control applications remotely. Only the host can share their screen during a session. Tuple also has great customer support.
Tuple is good for taking part in remote collaboration and pair programming. All participants have keyboard and mouse control, hence it's possible for anyone in a session to fix issues in code by controlling the host computer remotely.
USE Together is now Drovio.
Drovio allows one user (the host) to share their screen with team members. The team members can view and remotely control applications on the host's device as if they were in the same room.
Another convenient feature of Drovio is the ability for a second user to join a screen share session without having the app installed on their machines. A user can join a session link from a web browser if they have an invitation link (that was sent to them via email).
It is available for Windows, macOS and Linux.
Category: Multi-user sharing, editing and multiple user remote control.
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:
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.