In this article, we'll discuss five common challenges of pair programming that you may encounter.
Pair programming is a technique that has been around since the early days of software development, and it’s proven to be a very effective way to improve code quality, boost productivity and increase team camaraderie.
In a nutshell, two developers work together at one workstation. They write code in tandem, with one typing (driver) while the other reviews what they’ve written (navigator).
In this article, we’ll explore how pair programming can give your company a competitive advantage and help you stay ahead of the curve in today’s fast-paced world of software development.
Let’s dive into the benefits of pair programming!
Table of contents
More efficient work
People are often skeptical about pairing up with other developers on a project because they think that it’ll slow them down or cause them to make mistakes.
However, this couldn’t be further from the truth. Pair programming leads to more efficient work and faster project completion.
Let’s look at NASA’s research to get a better understanding of how pair programming can improve efficiency.
In 2001, NASA engineers conducted an experiment to see what impact extreme pair programming could have on their productivity.
The pilot project lasted 12 weeks, with two release cycles (subdivided into three two-week iterations) during that time.
And as you can see in the table below, the results were impressive.
Of the total lines of code written in this project, 912 were for production code, 1,135 were for test code and 498 were for testing scripts and utilities.
A prior, individual programming project required 2,144 lines of code–more than twice as much as the pilot pair programming production code.
The research results indicated that pairing up programmers can help them complete their projects faster and more efficiently than working alone.
In other words, teams of two coders were twice as productive as opposed to their solo programming sessions.
And there are many reasons why.
Unquestionably one of the biggest ones is that in pair programming you have two developers working on problems instead of just one dev trying to solve everything alone.
Or as Tod Huss, co-founder of Two Bit Labs, states, pairing works because it helps to avoid roadblocks, allows for quicker problem-solving, and keeps developers from going down the proverbial rabbit hole.
When two developers collaborate, they often come up with different solutions. This means that both solutions get tried out instead of just one.
This increases the chance of finding a better solution for that particular problem faster.
Additionally, pair programming increases efficiency because it provides a safety net. When one developer is working on a task, the other can take over if they get stuck.
That way there is no downtime or delays, which makes it easier to meet deadlines and get projects done on time.
Higher code quality
Pair programming has also been shown to improve code quality by reducing bugs and defects and increasing code readability.
In fact, a study published in 2000 by Cockburn and Williams suggests that pair programming produces higher code quality than individual work.
Among other results, they found that defects were reduced by 15% when comparing pairs vs individuals working separately, as you can see in the picture below.
Their findings come as no surprise considering the very nature of pair programming.
Pairing up prevents mistakes from being introduced because the navigator is always watching out for errors that might be made by the driver working on the task at hand.
Any bugs that arise while they’re working on a feature are caught quickly–often within minutes–instead of being discovered after hours or days have gone by.
And that is a great advantage because one thing that’s certain about software development is that you’ll have bugs.
Pair programming partners can find bugs even faster with a little help from technology.
Shake is one of the best tools for this purpose because it allows developers to test their applications in real-time and find all kinds of issues.
The process is simple: install Shake on your phone, open the app you want to test, and shake it. The tool will then tell you if there are any problems with your mobile app.
You can also record your screen with Shake, which makes it possible to create bug reports and share them with others.
It’s important to note that Shake is not a substitute for writing quality code with as few bugs as possible—but it can help your pair programming partners save time by quickly finding bugs that may slip through the cracks unnoticed.
Remember, if you want quality code, don’t compromise on the quality of its production.
Pair programming will ensure that the code is bug-free and has a high level of readability. Therefore, it’s worth the time invested in it.
Stronger communication between developers
In order for pair programming to work, both team members have to communicate with each other.
That makes sense because, after all, when you work in pairs, you have to talk. You can’t just sit there silently staring at the screen.
You have to participate in conversations with your pair programming partner about what’s going on and what you’re doing with your part of the project.
Shapeways, a 3D printing service company, does a lot of pair programming, and in the picture below you can see two of their developers immersed in one of the pair programming sessions.
Barry Schepers, their engineering tech lead, thinks that the key ingredient that makes pair programming so effective in their company is communication.
“We think the key to effective pair programming is communication, which has a heavy bearing on one’s personality and interpersonal skills. Of course, an engineer’s technical skills must also be adequate in order to help find a solution to a technical problem. But most of all, it’s about communication. Everyone needs to be able to communicate their thought processes, explain their solution to the other person and not be afraid to make mistakes.”
However, these words raise another issue, meaning that pair programming might not be everyone’s cup of tea.
For example, Carolyn Van Slyck shared her thoughts on Twitter, stating that pair programming makes her uncomfortable and that it’s not her preferred way of working.
If one developer isn’t willing to communicate, then they won’t be able to contribute as much value to the project as they could otherwise.
One way to deal with this issue is to encourage active listening between two pairing developers.
Active listening means paying attention to what your partner says, withholding judgment, and reflecting on what’s been said, so that you can respond appropriately and improve your communication.
When you use these skills in pair programming, you’ll be able to resolve communication differences and keep your project moving forward smoothly.
If both developers are willing to cooperate, pair programming builds stronger communication between them, which can eventually lead to better collaboration and improved efficiency.
It also helps to foster a sense of community and trust among the developers, and that is something that shouldn’t be understated.
Shared best practices
When two devs work together during pair programming, they inevitably learn new skills and techniques, give each other tips, and share best practices.
Learning from each other helps each developer become more efficient in their own way and smooth out some of the rough edges they may have developed while working independently.
As you might expect, this extends beyond just code.
The two devs can usually be counted on to share their knowledge and best practices across a wide range of topics, including design and architecture as well as code testing practices.
This is exactly what one Twitter user thinks when he states it’s more about pair development than pair programming, considering that these sessions are not merely about coding, but also about discussing and transferring different types of knowledge.
When people work in pairs, they have someone to talk to about what they are working on and get feedback on how to do things better or differently.
They also get a chance to see how someone else approaches problems so that they can incorporate those techniques into their own workflow.
The result is that both devs will come out of the session with new knowledge about best practices they didn’t have before they started pairing, and be more confident in their solutions, as the study suggests.
Finally, pair programming allows developers to share best practices with each other in real-time–instead of having to refer back to previous projects or documentation.
And learning from one another on real projects is a great way to become more proficient in their craft.
Remember, pairing can be difficult for some developers because it requires time management skills and self-discipline.
But if they’re able to work in this mode successfully, devs will be amazed at how much they learn from their pair programming partner—not only about the task at hand but also about their best practices for solving different problems.
Collective code ownership
Collective code ownership means that responsibility for the code quality is shared among pair programming partners.
The partners take turns writing code and reviewing each other’s work.
As a result, each developer has equal rights and responsibilities over the code they write together, and each of them should feel like they own it.
Collective code ownership offers numerous advantages:
- Developers have more freedom to make changes to the codebase because they don’t need approval from anyone else in order to do so.
- Code quality improves because everyone has an incentive to keep their part of the code clean and well-designed.
- Developers feel more invested in the project because they have a stake in every part of it, not just the parts they personally work on directly.
Here’s a visualization of the biggest benefits of shared code ownership.
These benefits combined help foster a sense of teamwork, instead of competition between developers.
It also means that if one developer leaves the team, their knowledge doesn’t go with them–the other pair programming partner knows how everything works too.
As Mike Tecson, a senior lead software engineer at ClubLabs, explains, this prevents an individual developer from becoming a single source of truth for the code that’s been written.
Collective code ownership also helps avoid the “not my problem” syndrome that can occur with traditional programming practices.
Every developer is responsible for ensuring that each line of code works correctly and meets the overall requirements of the system.
This makes it easier for everyone to feel accountable and proud of their work.
Although collective code ownership requires a significant commitment from both developers as they must be willing to take responsibility for the code that they haven’t personally written as drivers, many people find it better because it reduces the burden on individual developers.
It also helps promote teamwork since both developers have a shared understanding of how their part fits into the larger system.
Faster training of new team members
One of the biggest benefits of pair programming is surely the efficiency of onboarding new developers.
When a new dev joins the company, they’ll have to learn how to use all the tools, libraries, and frameworks that are used by the rest of the team.
This can be a time-consuming process and often results in developers who are unfamiliar with one or more parts of the codebase.
Pairing with a more experienced developer will allow them to get up to speed with the project much faster than if they were left to their own devices.
They can learn from someone who knows how everything works together, as well as pick up valuable knowledge about what’s good practice in your company’s codebase.
For example, Avery Yen and Bella Bai, software engineers at Pivotal Labs, think that pair programming enables inexperienced developers to become productive from day one.
In a traditional environment, new developers would be assigned one or two mentors to help them learn different parts of their codebase.
But, this can take days or weeks to fully understand all aspects of a system.
With pair programming, junior developers can be given access to an expert immediately and start working on real problems from the start.
This means that they’ll get the ropes much faster than they would if they were learning by themselves.
That is great because research conducted by Brandon Hall Group found out that a strong onboarding process can improve new employee retention by 82%!
They’ll get the chance to get their hands dirty from day one and get a taste of how exciting working on real projects in your company can be.
And that can really make a difference, considering that more than 58% of the companies focus their onboarding just on processes and paperwork.
In this article, we’ve tried to explain the six biggest benefits of pair programming for your software development team.
Some of them are improved productivity, increased code quality, better communication skills, and faster onboarding.
However, there are also more subtle benefits that accompany these big ones, such as improved work culture and partner bonding that can help you build strong development teams in the long run.
In the end, we would like to emphasize that pair programming is not without its set of challenges.
It requires time and effort to implement it successfully in your company. But if you do it right, you’ll definitely see results!