Pair Programming Pros & Cons

In mid-2015, we began experimenting with pair programming at Red Airship. We’ve heard many differing opinions, and we went ahead anyway. [P.S. we do agile development]

After 12 months – we built better products, client satisfaction significantly improved, and all our developers (and designers) wanted to continue working in pairs. We have since adopted Pair Programming in our work at Red Airship.

What is Pair Programming (aka “pairing”)

Pairing means having two developers working on the same task at the same time. It’s not the same as splitting the to-do list into sub-tasks and having the individuals tackle them in parallel.

When developers pair at Red Airship, they use two sets of keyboard and mouse connected to the same computer, so they don’t have to pass keyboards around. They also have two or three screens so they can work with more real estate.

The developer who is actively programming, the “driver”, focuses mainly on writing code. At the same time, the “navigator” helps to spot tactical and any upcoming strategic issues. The navigator – as the extra pair of eyes – looks ahead and help spot tactical and strategic issues in what the driver is doing on the keyboard.

Tactical issues like syntax errors, typos, not following conventions, are caught in real time as the navigator covers the driver’s blind spots. Strategic issues like wrong patterns, approach, design are worked out during discussions and again while execution as the navigator looks much further ahead. The pair takes turns and switch roles frequently.

Photo credit: https://www.thoughtworks.com/insights/blog/effective-navigation-in-pair-programming

Why should two people do the work of one?

Besides improved design quality, reduced defects, reduced staffing risk, enhanced technical skills, improved team communications; working together is also quite fun 🙂 Two is just right; any more and you may start to border on groupthink.

While this may seem like a counterintuitive, lavish use of our most important resources (ahem, developers), here’s our review of the pros and cons of Pair Programming.

Pros of Pair Programming

• Faster, Better Solutions

Every developer has their unique background and experience. When two developers are tasked to solve a challenge together, magic happens! The number of potential solutions to one problem more than doubles. We can come up with better-designed solutions without impacting time to deliver.

Talented programmers are also able to come up with great solutions alone. It’s just much faster with two brains 🙂

• Bad habits, Begone!

The bad habits that developers indulge in when they work alone? They don’t do that in pairs because someone else is watching.  

Sometimes developers feel compelled to over-deliver and end up skimping on good development habits. Automated tests? Those can wait after Deanna’s Friday campaign!

Although it appears that value is delivered to the clients quicker, poor habits reduce deployment confidence in the next release and increase the chances of regression and integration bugs. Future developments might be delayed or slowed down.

Bad habits can seem harmless enough now, but issues usually crop up down the line. The domino effect of technical debt will likely offset any revenue brought in by the business initiatives they were so eager to support.

Also tied into the next point: the seniors feel obligated to be role models, and juniors emulate what they see, thus picking up good development habits on-the-job.

• Leveling Up Developers

When developers work together, they learn from each other consciously and subconsciously. This transfer of knowledge includes coding practices, design patterns, new technologies, tools, domain knowledge, hacks and tricks, and even some aspects of personal development.

This transferring of knowledge also applies to experienced developers too. I have been programming for the last 20 years, but I am still learning new things all the time.

Experienced developers have their way of dealing with code, so it can be refreshing to see different approaches from junior developers. I once worked with a developer who just started picking up CSS, and was pleasantly surprised by observing her method of solving issues.

When you teach someone, your understanding of the subject deepens. This collective growth is valuable to both our clients and the company as a whole. Also, the project is now less dependent on any one developer – the team shares the know-how and experience, which leads us to our next point.

• Breaking Down Silos and Heroes

In some companies, when the lead developer of a project takes a break, the project goes into hibernation or maintenance mode until he returns. Have issues with component Y? Let’s wait till Don comes back!

In worst case scenarios, the lead developer holds the project hostage and leaves everyone hanging. All these can happen when individual developers stay within their boundaries and own specific components.

Conversely, a common complaint of developers is that they get burnt out as they cannot take proper vacations. Working in pairs allows someone to go on leave while the other holds the fort. Add rotating pairs on top of this, and the whole team benefits from the flexible allocation of tasks and resources because anyone can work on any story.  

When pairs rotate, domain knowledge is dispersed to everyone in the team. Everyone understands what everyone does, enabling more efficient team communication. Now Don can go on his vacation freely, knowing that he is not a bottleneck to the project.

• Developer Morale and Satisfaction

During the initial stages of implementation at Red Airship, each developer in our team tried pairing over a few sprints for starters. Feedback was very promising, with all of our developers reporting improved productivity, confidence, and work satisfaction.

“In an online survey of pair programmers, 96% of them stated that they enjoyed their job more than when they programmed alone.
Additionally, 95% of the surveyed programmers said that they were more confident in their solutions when they pair programmed. A correlation exists between satisfaction among programmers and their confidence in the code; i.e. the pairs enjoy their work more because they are more confident in it.”

Williams, Laurie; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). “Strengthening the case for pair programming.”IEEE Software.

As the points of contact between developers increase, we also noticed improved relations between the pairs. In other words, stronger bonds formed as a result of pairing, and the whole development team became more close knit.

We’ve always known that happy people do their best work! All these translated into spending more time on building higher quality software and less time on tracking and fixing bugs.

Cons of Pair Programming

Even with all the stated benefits, Pair Programming is not a silver bullet without any cons. Pairing is a social skill that has to be learned – and human interactions can be unpredictable. And with other people in the equation, personalities, feelings, beliefs and egos will surface; things that add complexity to a situation.

• Only Fast As…

This bottleneck effect is mostly observed in a senior-junior pairing, especially when the junior takes on the role of the driver. The pair ends up going only as fast as the slower team member.

The day-to-day pacing does feel slower, but the problem does not take more time to solve. Overall, time is shaved off the project because higher quality code has fewer bugs (fixing bugs take up a lot of a developer’s precious time)!

This effect is understood, weighed, and embraced at Red Airship because we emphasize quality over speed. We are also very fortunate to have buy-in from senior developers who care about team development

• More Talk, Less Coding

A lot more time is spent explaining concepts and decisions to the junior developer. Programming feels inefficient with so much talking going on. Plus, all the thoughts in your mind will now need to be translated into words and communicated to another person. The urge to do things instead of pausing to explain can be present in more experienced developers.

Good communication is a sign of clear and coherent thinking, and people only get better when practicing this repeatedly. It is an overall benefit to the individual as well as the team.

Furthermore, verbal rationalizing evolves through debates and results in better, simpler explanations. Great comments in the code are a result of a good thinking process. And anyone can & will appreciate simple succinct comments!

• Scheduling Issues

We do not enforce strict working hours at Red Airship, and our team members work at whatever time of the day in which they are the most productive. It may cause some issues when individuals in a pair work best at radically different periods of the day.

We quickly learned that this isn’t so much of an issue as we thought it would be.

We found that pairs always adapt to each other’s schedules within a week. Even with different individual work timings, they can find a sweet spot of compromise. These adjustments happen organically without any management’s intervention, and we’d like to think of it as a result of our cohesiveness and culture of team accountability.

Also, our developers don’t spend all their time coding – they also engage in other equally important activities such as reviewing work with the UX team, research on new technologies, doing code cleanup and maintenance, and writing documentation. Remember, pairing does not need to occur 100% of the time!

• Code Ownership

Developers take pride in owning a piece of code. It improves code quality when an author feels responsible for its bugs. So, who owns the code when two people produce it?  

There is a lot of value of collective ownership of code. We foster a joyful, cooperative work environment conducive to collective growth. The team understands that owning a piece of code feels good, but building great products together feels better.

Our final thoughts on Pairing

This article highlights our experience and successes in implementing Pair Programming in Red Airship. We believe that it worked for us because we are very fortunate to have:   

1) Senior developers who are passionate not just about honing their skills, but also about growth of the team

2) Clients who were open to exploring and experimenting with different ways of working

There is no one right or wrong way to Pair Program, and most importantly – not every company can or should implement pairing. At Red Airship, we view this as a task of matching problem complexity and pairing types, and this is a topic we’d like to share more in future articles.

Pair Programming Best Practices

What can you do to help cultivate an environment in which pairing works?

We are by no means an expert in this field, but some of our groundwork and learning paid off. Our hope is that you can learn from our experience too.

1. Remove the fear of failure from your workplace. Cultivate an environment that encourages experimentation and openness. When people are not bogged down by the fear of failure, they can do better work.
2. Promote the right values instead of tracking performance via metrics like hours logged and the number of commits. Having the whole team aligned with the same set of values allows them more freedom to do what it takes.
3. Try pairing outside of the development team too. We also tried pairing within the UI/UX design team with the same great results. Pairing is ultimately a new way of working, not just in agile/development. Stay tuned for more articles!

Want to pair with our developers and work on cool projects?

Find out more and apply to our apprenticeship program at Red Airship.