Pair Programming

What is Pair Programming?

Pair programming (PP) has become popular in the research and software industry as well as being studied for a number of years in computer science courses with positive findings on student performance and attitudes.

In the practice of pair programming, two programmers work together at the same workstation. You’ll have one at the keyboard and one that acts as an observer. The programmer at the keyboard is called the “driver” and the observer is known as the “navigator”.

In paired programming, neither programmer exclusively works as the driver or navigator. The idea is for them to switch positions at different times. The job of the driver is to focus on writing the code, while the navigator reviews the code and focuses on the larger objectives of the project.

How Is It Good for Improving Developer Skills

Regardless of the type of pairing, paired programming has something to offer both members of the team. Of course, an inexperienced developer is going to learn more from an experienced partner, but a junior developer can often help the more experienced partner to look at things in new ways.

Better Quality

Pairing can improve quality in a number of ways. To start, you have two professionals looking at the problem instead of one. Each professional will have their own unique experiences and insights, and each programmer will approach the issue in a different way. A good pair looks at all of their options, then they go with the solution that works best.

In addition to that, the navigator acts as a reviewer while the driver writes code. This means that mistakes can be caught while the code is in the process of being written, and improvements can be suggested during the development process.

Lower Costs

One common misconception is that pairing will increase costs because you have two people doing a job that a single programmer could do on their own. Pairing actually brings down costs because it reduces the number of issues that you have in the review process. This means less troubleshooting and fixing after the initial code is written.

Creates Learning Environment

If you are looking to improve the skills of programmers, pairing provides a good environment for team members to share knowledge. This can be especially good for junior programmers that lack experience. By working with an expert, they can learn in real-time as they work.

Team Building

Nothing builds trust and a sense of shared purpose like actually working together. With pairing, programmers get to learn from each other, they become familiar with the skills that their co-workers have, and they get to know each other. Pair programming works as a great solution for lowering costs and improving the quality of the work that is performed.

Beyond that, it offers a great environment for programmers to learn from each other and it is a good way to build a more cohesive team. By trying pair programming, you are taking a step to increase productivity in a work environment that your employees will find more enjoyable.

How to pair

Driver and Navigator

These classic pair programming role definitions can be applied in some way or the other to many of the approaches to pairing.

The Driver is the person at the wheel, i.e. the keyboard. She is focussed on completing the tiny goal at hand, ignoring larger issues for the moment. A driver should always talk through what she is doing while doing it.

The Navigator is in the observer position, while the driver is typing. She reviews the code on-the-go, gives directions and shares thoughts. The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacles.

The idea of this role division is to have two different perspectives on the code. The driver’s thinking is supposed to be more tactical, thinking about the details, the lines of code at hand. The navigator can think more strategically in their observing role. They have the big picture in mind.

A common flow goes like this:

• Start with a reasonably well-defined task
• Agree on one tiny goal at a time. This can be defined by a unit test, or by a commit message, or written on a sticky note.
• Switch keyboard and roles regularly. Shared active participation keeps the energy level up and we learn and understand things better.
• As navigator, avoid the “tactical” mode of thinking, leave the details of the coding to the driver — your job is to take a step back and compliment your pair’s more tactical mode with medium-term thinking. Park next steps, potential obstacles and ideas on sticky notes and discuss them after the tiny goal is done, so as not to interrupt the driver’s flow.

Ping Pong

This technique embraces Test-Driven Development (TDD) and is perfect when you have a clearly defined task that can be implemented in a test-driven way.

• “Ping”: Developer A writes a failing test
• “Pong”: Developer B writes the implementation to make it pass.
• Developer B then starts the next “Ping”, i.e. the next failing test.
• 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” approach: Write a failing test (red), make it pass with the minimum necessary means (green), and then refactor.

Remote Pairing

Are you part of a distributed team, or some team members occasionally work from home? You can still practice pair programming, as long as both of you have reasonably stable internet access.

The Setup

For remote pairing, you need a screen-sharing solution that allows you to not only see, but also control the other person’s machine so that you are able to switch the keyboard. Many video conferencing tools today already support this, so if you’re working at a company that has a license for a commercial VC tool, try that first.

Tips

• Use video: Since people communicate a lot through gestures and facial expressions it is nice to see the shared screen and your pairing partner’s video at the same time.
• Planning and designing: Use collaborative online visualization tools, to reproduce the experience of sketching out things on paper or a whiteboard.
• Audio experience: Look for a quiet area and use a good headset, maybe even with a directional microphone. If you can’t get away from the noise, “push to speak” functionality can also help. To avoid distractions on your side, noise-canceling headphones are your friend.

The Advantage of Pair Programming

There are several advantages of pair programming as reasons you should consider.

• Two heads are better than one. If the driver encounters a hitch with the code, there will be two of them who’ll solve the problem.
• More efficient. The common thinking is that it slows down the project completion time because you are effectively putting two programmers to develop a single program, instead of having them work independently on two different programs. But studies have shown that two programmers working on the same program are only 15% slower than when these programmers work independently, rather than the presupposed 50% slow down.
• Fewer coding mistakes. Because there is another programmer looking over your work, it results in better code. In fact, an earlier study shows that it results in 15% fewer bugs than code written by solo programmers. Plus, it allows the driver to remain focus on the code being written while the other attends to external matters or interruption.
• An effective way to share knowledge. Code Fellows talk about how it could help programmers learn from their peers. It would allow programmers to get instant face-to-face instruction, which is much better than online tutorials and faster than looking for resources on the Internet. Plus, you can learn things better from your partner, especially in areas that may be unfamiliar to you. Developers can also pick up best practices and better techniques from more advanced programmers. It can also facilitate mentoring relationships between two programmers.
• Develops your staff’s interpersonal skills. Collaborating on a single project helps your team to appreciate the value of communication and teamwork.
• Having a backup knowledge of the program, If one member of the pair resigned, you would have another programmer who knows the entire program.

The Disadvantage of Pair Programming

• Lack of will. Some simply prefer and work better alone.
• Wrong tasks. Pairing at the wrong time can be both time consuming and inefficient.
• One can slow down the other. If one is a slow thinker/typer or unfocused it can slow down the other one as well.
• More talk less coding. You might end up explaining things more often which would result in less code typing.
• Lack of code ownership. Since two developers are responsible for the code both can feel that the other one is more responsible. If an error occurs there could be a discussion of who should fix it or if it should be done in pairs again.
• Loss of confidence. Some developers find that pairing a lot loses their confidence in coding alone and they want to pair on more things than necessary.

Pair combinations

Senior — Senior

Even though you’re a senior you can make mistakes, won’t always see the best solution and will always have something more to learn. Pair programming could be a good way to fill those gaps.

Senior — Junior

This is great to speed up the learning curve for the junior. The junior may have a more open mind and question things the senior just got into a habit of doing. This could be a great way to increase experience across the team.

Balance is important. If cooperation is not good, the junior might end up just watching. The senior could be annoyed by explaining and feel resistance in his/her development flow. Make sure to find a good balance that works for everyone. E.g if the manager/boss is clear about the importance of everyone’s learning, the senior might feel better taking the time to explain. The employer invests in a productive team so pair programming could, in this case, be a good investment for the company. That could make the senior developer more motivated to teach and less frustrated by slowing down his/her coding.

Junior — Junior

This combination could significantly improve productivity and quality. Since juniors have more to learn and more questions, they can now learn from each other and develop their skills faster.

Metrics and Results

The source code was later analyzed using a script. It traversed the Git history commit by commit to calculate metrics changes over time.

The script used proven services and platforms: CodeClimate (quality, style, security issues), TravisCI (passed/failed builds), GitHub (pull requests, commits, comments), Heroku (deploys), Git (commits, conflicts), SimpleCov (code coverage).

Velocity (Burn-up Chart)

Velocity measured by Story Points burnt by the team on a daily basis

Velocity was measured by Story Points burnt by the team on a daily basis. A single User Story was considered “done” when the code was merged to master branch, deployed, tested and accepted by a coach.

Code Quality

Code Quality measured by CodeClimate

Code Quality was measured by the CodeClimate platform. The platform uses static code analysis to check for issues with complexity, duplication, security, style etc. Quality is represented by GPA — the single number in the range from 0.0 to 4.0, where 4.0 means “Excellent” (A) code quality, 3.0 is “Good” (B), etc.

Code Coverage

The percentage of code covered by tests was calculated using the SimpleCov tool.

Quantity Metrics

Quality Metrics

Pairs vs Solos:

• Pairs can build the project 56% (week 1) and over 2times (week 2) less often.
• Pairs created 43% (week 1) and over 5times (week 2) less Pull Requests.
• Pairs created almost 3times (week 1) and almost 2times (week 2) fewer Commits.
• Pairs had 63% (week 1) and 10% (week 2) fewer conflicts in Git.
• During the 1st week, Pairs wrote 7% more comments through GitHub (Pull Requests / Issues).
• During 2nd week, Pairs did not write any comments, while Solos wrote 24 comments.

It’s fun

It takes some practice to get used to it, but once you have a process containing pair programming, your team will feel like it accomplished a lot more while learning faster and getting to know their colleagues better. Collaborating that closely would really make you feel like you’re part of a team.

Conclusion

It might take some practice to get super productive doing pair programming and to learn how to identify which jobs it might be useful for. After crossing that learning curve (which should only be a matter of days, maximum weeks), the advantages greatly outweigh the cost.

So I’d advise every team to at least give it a spin, you’ll probably find much value in it.