5 common challenges of pair programming

The main idea behind pair programming is that two developers work together on the same task, side-by-side, at one computer.

One developer writes code (driver) while the other one observes and reviews every line of code being written (navigator).

If you’re new to pair programming, it might seem like a strange concept. After all, why would you need another developer working on your code?

The truth is that partnering up can be an excellent way to work through a problem, improve productivity and quality of code, as well as reduce the number of bugs introduced.

However, it doesn’t come without its set of challenges. Here are five common issues that you may encounter when implementing pair programming.

Excited?

Let’s explore!

Office space is not suitable for pair programming

If you’re working in an office with other people, there are many things you need to take into account before trying pair programming.

It takes up twice as much desk space as when you’re alone.

You need two monitors, two mice, and two keyboards if you want one developer to be able to concentrate on typing while the other one concentrates on their screen.

You also need two chairs, and multiple connectors and cables, as you can see in the picture below. It lists the basic requirements for successful pair programming.

While these technicalities are more or less manageable, there are more things to consider when deciding whether your office is suitable for pair programming or not, and what adjustments are needed.

For example, most office spaces are designed for independent work, not collaboration.

There are few shared workspaces or meeting rooms, and often there isn’t enough space for two chairs next to each other at desks set up for individual work.

But if you want to reap all the benefits of pair programming, you need to find a way to make it work for you.

For example, doing it in an open office can be a recipe for disaster because you and your programming partner could be distracted by other people’s conversations, the sound of keyboards, and the constant movement around you.

The solution? Find another space within your company where you can go and code together. This could be in a conference room or even just a smaller office with two desks side by side.

At Lawnbot, for instance, they practice pair programming in an isolated space where two developers have enough room to comfortably sit together and code, which is a great way to boost the productivity and quality of their output.

You can also try using a standing desk.

Standing desks have gained a respectable amount of popularity in recent years because they reduce back pain, improve posture, reduce symptoms of carpal tunnel syndrome, and keep circulation going.

When it comes to pair programming, standing desks can also help avoid having people sit uncomfortably close together and feel like they’re invading personal space.

That’s why Precision Infinity, a software development company, incorporated standing desks into their pair programming sessions.

They’ve also opted for a curved standing table because they’ve noticed that it makes it easier for them to look at monitors, and leaves more elbow room.

Remember, you can’t just put two developers in one room and expect them to be able to write code together. Making the office suitable is essential if you want pair programming to take place.

Therefore, it’s important that you make sure that your office is set up beforehand so that it can accommodate the needs of a pair of developers.

The code doesn’t lend itself to pair programming

The basic idea behind pair programming is that two minds are better than one, so by pairing two developers together, they can catch each other’s mistakes and come up with better code solutions faster.

However, in reality, this isn’t always the case because it can be hard to find two developers who share the same vision.

For example, you could pair up two developers with different ideas about how things should be done.

This usually leads to friction about best coding practices that can easily escalate into big arguments over style preferences or coding conventions.

An answer from the Quora thread below is a good confirmation of that.

One way to mitigate this problem is to make sure that you’re pairing developers who have complementary skill sets so that they can go back and forth between writing code and reviewing each other’s work.

Everyone should have a similar amount of experience and know what they’re doing. Otherwise, it’ll be hard for both developers to contribute equally and for the pairing session to be productive.

That is precisely what Moïse Zapater, an engineering and innovation director at Septeo, suggests: working in pairs will help expert developers to write better code in real-time as they’ll challenge each other to produce more reasonable solutions.

When it comes to code, there is also one challenge worth mentioning. Certain tasks simply don’t lend themselves well to pair programming.

For example, if you’re working on a large codebase with a lot of dependencies, it can be difficult for a second developer to get up to speed quickly enough to make this method effective.

On the other hand, if the task is too simple, pair programming might also not be the ideal option as there’s little value in having two people working on something that could easily be done by one developer alone.

However, pair programming is a great tool for tackling large problems, where one person simply can’t see the whole picture. Weblab, for instance, uses it for complex pull requests review.

Additionally, when you’re stuck trying to solve an issue and can’t think of any good ways to move forward, pair programming provides an excellent way of working through the problem and coming up with new ideas.

As you can see, the biggest benefit of pair programming is that it can lead to fewer bugs in code since two people are looking out for mistakes.

Pair programming also increases the likelihood that both developers will understand the problem well enough to solve it, which can help avoid common pitfalls like code rework and missed deadlines.

However, this type of work is not a universal solution to all problems.

It’s just one tool in your toolbox, and it’s best used when you have two experts who can work together well on complex tasks that need fresh perspectives and ideas.

And that is something worth taking into account when planning your pair programming sessions.

Pair programming can be costly

The most common arguments against pair programming usually fall into one or more of these categories:

• Pairing isn’t necessary and there are better ways to collaborate
• Pairing takes too long and slows down iteration cycles
• Pairing is inefficient; one developer could do all this work alone in less time (and cost)

While it’s true that you’ll need two developers to do the job and that pairing can slow down their velocity, the benefits of pair programming far outweigh the apparent overhead.

In fact, research conducted by Cockburn and Williams discovered that, although it takes about 15% more time, pair programming has been shown to improve code quality and reduce defects by as much as 15% when compared to solo programming.

Pair programming also has a number of other benefits that make it an invaluable part of any software development process.

First, it increases productivity. By having another developer around to help with design decisions and code reviews, you can finish tasks faster while still producing high-quality code.

In fact, a study titled The Case for Collaborative Programming has revealed that teams outperform individual developers as they’ve completed their tasks 40% faster.

That comes as no surprise as developers gain from each other’s knowledge and experience.

When two developers work on the same task, they can share their knowledge about the issue and technology in question.

This results in new ideas, better solutions, and overall improved efficiency.

Additionally, pair programming encourages communication between developers, which leads to fewer misunderstandings and miscommunications, resulting in fewer bugs, rework, and frustration.

Developers become more engaged in the development process, resulting in higher morale and overall satisfaction while doing what they do best—writing code!

In fact, the previously-mentioned Cockburn and Williams study also stated that 80% of developers who do pair programming are more satisfied at work because of it.

And the impact that satisfaction has on productivity is already well known and needs no further explanation.

From everything that’s been said, it’s pretty clear that, although pair programming can be costly in terms of time and resources, the benefits are worth it.

Especially as it’s a great way to improve your team’s performance as a whole.

It helps members of the team share their knowledge, skills, and experience with each other, which is invaluable for any company that wants to grow its software development capabilities.

There may be issues with code ownership

Working as a pair can be challenging when it comes to code ownership issues too.

Finding a balance between how much each person contributes to the project is key to ensuring that both developers feel invested in the code they’re writing.

The first thing we need to understand is what code ownership actually means. The term isn’t used much outside of the software industry, so it’s worth clarifying exactly what it implies.

In a nutshell, it refers to who gets credit for writing code, and more importantly who has the authority over changes made to existing code bases.

In pair programming there may be no clear owner of the code being written, because two people are writing it together.

However, there are some cases where certain frictions can arise.

For example, the developer who is “driving” the keyboard may be tempted to write all the code themself, leaving the programming partner with nothing to do but watch.

This can lead to confusion over who owns what part of a particular piece of code and who should be making decisions about what goes in there or how it’s designed.

When that happens, things can get complicated fast.

To avoid this problem, it’s important that both developers be actively involved in the development process.

This can be achieved by having pair programming partners switch roles frequently (e.g., every 25-30 minutes), so that each partner gets a chance to drive and be driven.

Luckily, the Pomodoro technique will help you do this seamlessly.

The idea behind this technique is simple: you set a timer for 25 minutes and work until it goes off, then switch roles.

This will also help keep things interesting and prevent boredom from setting in too quickly.

Another challenge is that pair programming can lead to a lack of clear rules when it comes to accountability and responsibility.

When you are paired up with another developer, they may be tempted to blame you if something goes amiss or take credit for your ideas.

The best way to avoid this situation is to have clear expectations from the beginning about how much time each member will spend working on the project and what they’ll contribute before they begin working together in pairs.

A good approach is to define a goal stack before you start working. You should list the goals that you’re working towards, and their order of importance.

This doesn’t have to be anything fancy—just a few goals written by hand, as in the example above, will do the trick and help you accomplish the goals faster, switch between the roles more efficiently, and deal with accountability better.

For example, if you and your counterpart work on the project from start to finish, it would be fair for you both to have equal ownership of the code that has been written and get the recognition (or blame!) that may come from it equally.

And if you are pairing only on the parts of the project, you’ll have a better understanding of how to divide up your work and code ownership.

Pair programming is just too difficult sometimes

Many developers find pairing to be an uncomfortable experience.

Some don’t like having a second person in their workspace. Others don’t like that other developer is looking over their shoulder while they work.

They may feel that it slows down the process, or that their creative flow will be interrupted by a second person continually “correcting” their code.

For some people, especially introverts, this kind of social interaction drains their energy. This can make them feel anxious and stressed out instead of productive and happy.

But with the right attitude and a little practice, you can ensure that everyone gets what they need from the experience without sacrificing the benefits of pair programming.

Plus, as it can be good for developers’ morale and confidence in the work they’re doing, it’s worth the effort to make sure that this type of collaboration works for everyone involved.

First, you should promote pair programming activities among your developers as a great way to learn from one another.

For instance, if the developers are working on something new or unfamiliar, having someone else around can help them stay focused and maintain a high level of productivity.

It can also be a great substitute for tried and tested techniques such as rubber duck debugging.

It’s basically a method of debugging, whereby a developer fixes the code line by line, explaining each step aloud to a rubber duck (or other inanimate objects).

This helps the developer to detect any errors in their thinking process.

In pair programming, instead of a cute duck, developers have another expert by their side.

Basically, pair programming forces developers to explain what they’re doing in detail so that their partner understands what’s going on in their head and can give feedback in real-time as they code together.

This creates an opportunity for both parties to become more knowledgeable about their craft.

And you can discover just how beneficial it can be when it comes to sharpening their skills in this user’s experience on Reddit.

Reddit user practiced pair programming often and found it invaluable for making him a more skilled developer.

You should also encourage pair programming as a way to build trust and rapport between developers.

When two developers sit down together at a single computer, they’re forced to communicate clearly with one another. They can’t hide behind their screens.

When they’re able to talk through a problem, they become more than just coworkers— they become allies who support each other in their work.

This leads to better collaboration and more productive conversations about how to solve problems together.

To sum up, pair programming requires some effort from both parties, but with a positive attitude and a little practice, you can ensure that everyone gets what they need from the experience without sacrificing the benefits.

Conclusion

As you can see, the pair programming process is not without its set of challenges.

In this article, we tried to describe the five most common issues and provide you with the best ways to tackle them.

While some are directly related to the developers’ skills and experience level, others you can overcome by adjusting the process itself.

We hope that by reading this article, you were able to find a way to improve your own pair programming process and make it easier for you and your team of developers in the future.