Skip to main content
Author
Posted On 14 Jun 2021

Talk to our experts about Pair Programming

I agree to Privacy Policy

If we asked you and your colleague to share a computer at work, will you be comfortable? Probably not! And rightly so, after all both of your productivity might take a hit, time management would most definitely be a problem and probably you’ll get no work done! But what if we told you that a set of people in your company – the developers – might benefit from it? Sounds strange? Let us explain more about Pair Programming. 

Pair programming is a concept where two developers use just one machine to work, meaning they work simultaneously on a single block of code. While one acts as a driver – writing codes – the other will play a navigator’s role, ensuring the accuracy of the code and navigating the driver. The two developers can switch roles at any time of the process.

We can assume you must have a long list of questions by now. Stay with us as we walk you through the entire process in detail.

You may be wondering why waste a resource in getting the job done by two when it can be taken over by one, right? It might come across as a misuse of valuable resources but according to the Association for Computer Machinery (ACM) and the University of Utah’s Computer Science school, while the pair programming technique can take 15% longer, it also ensures 15% lesser defects.

Pair programming was first introduced to an extreme programming software development technique by Kent Beck in the ’90s. Extreme programming is an “agile project management methodology that supports frequent releases in short development cycles to improve software quality and allow developers to respond to changing customer requirements.”

According to Beck, “Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team’s practices. Pairing”

pair programming

Why opt for Pair Programming?

The adoption of pair programming has received mixed reviews from across the developer's fraternity. The statistics above would have already set the tone. However, some agile development organizations prefer to take the pair programming approach for its common advantages.

Bug and error reduction

We had already shared the ACM report, which shows that pair programming results in 15% lesser defects. With two heads on the job – the driver and navigator – the codes are checked for accuracy in real-time and typos, bugs are identified on the go. 

Cost-effective

The common misconception is that pair programming is often more expensive. Yet, just assuming the cost of two resources would not be ideal. One must remember that while bearing the cost of two developers, the overall time consumed on the project will also be relatively lesser when compared with the time taken by a single developer to do the same job, who would take lesser time making corrections.

Increases team’s knowledge level

Pair programming leads to better sharing of knowledge across the development team. A relatively new coder, while working with a subject matter expert can gain expertise faster as opposed to when working in silos. Similarly, several other such team collaboration enhances peer-to-peer learning.

Increases job satisfaction levels

Another research report – Strengthening the Case for Pair Programming – suggests that 96% of pair programmers preferred to work in teams and enjoyed the company of another programmer. It is known that when working in teams, professionals get a boost to their confidence levels and enhances their networking skills. In fact, over a period of time, enhanced teamwork improves the overall quality of work.

Why is Programming in Pairs Better than Code Reviews?

Code reviews are reviews of code written by a programmer to find defects and deflections. This process ensures that the testing of the codes is combined with quality control and improves the overall result.

However, where most teams face challenges is identifying a resource to just check another programmer’s codes and understand the reasoning behind them. The process is tedious and is often tested only when new functionality is added to an existing code.

However, with pair programming the entire process shifts. Codes are reviewed in real-time and both programmers can switch roles to keep the momentum alive.

pair programming

What Are the Pitfalls of Pair Programming?

Okay, so let’s be honest, not everything can be rosy! While we have listed the benefits of pair programming, there is no doubt there are pitfalls too and we want to ensure you are well-informed before you can decide on whether pair programming will work for you.

It is expensive!

It cannot be simpler than this. Two programmers on each code are bound to increase the overall cost of the development work. However, considering the scenario as explained in the pros, the overall cost is often less than double.

It can be counterproductive

Pair programming is often called “programming out loud” and even though communicating through the entire programming process may seem to be a good idea, more often than not that’s not a strength for a lot of developers. Not all programmers can express themselves equally.

Additionally, varying experience levels may slow down the more experienced one to maintain pace. Assuming that all developers will be comfortable working on shared machines may be counterproductive.

Innovation and creativity may take a hit

Imagine if a pair of programmers don’t get along or don’t carry a similar thought process. Not being able to assess the partner’s skills and gain trust may lead to lost innovation and creativeness. It could also lead to conflict between the two developers if they are not in line with each other’s process. Additionally, varying experience levels may demoralize the other programmer from expressing themselves fully.

Methods of pairing

Pair programming is a lot more than outing two developers to work together. Since its inception practitioners have been continually working to develop models that would work in different scenarios. Practice and experiments have been improved and these techniques have been refined to suit requirements. Here are a few methods adopted while pairing.

Driver-Navigator – This is the most popular and commonly used method in pairing. As explained earlier, the two programmers take the role of a driver and navigator respectively. Both need to interact consistently and also switch roles to keep the interest and momentum alive.

Ping-pong – This approach needs two keyboards connected to the machine, enabling both the driver and the navigator to work in quick turns. The first person writes a failing test and the second person gets it to pass, followed by the second person writing a failing test and the first person gets it to pass. This process works exceptionally well between two experts.

Backseat navigator – This is typically adopted when the driver is relatively less experienced than the navigator. The navigator takes the backseat and instructs the driver on how to solve a problem and also reason out why the solution is the best option. This especially works well for newer team members.

Tour – This could be opted for in-between an ongoing process. For example, if the navigator from a pair were to leave the project mid-way, a new resource will be pulled in, who will now act as a driver and take a tour of all the details. Whereas, the other person will become the navigator because they have a deeper understanding of the code.

Distributed pairing – A setup where the two programmers are connected virtually to work on a code, rather than working face-to-face as practiced traditionally.

These are not the only pairing methods. There are many other methods with these being the most popular. In each one of these techniques, the driver and the navigator must get along and can communicate seamlessly.

How to pair effectively?

The simplest way to start par programming is by partnering two developers and letting them build the architecture, code and then effectively test each code in the true sense of a partnership. The most ideal way is to have both programmers of the same expertise level however, in the case of newer resources in the team, it would be ideal to pair them with someone with greater experience. And most importantly, ensure that the programmers switch roles often.

Conclusion

Pair programming has its pros and cons but it works wonders in teams that have a higher tolerance and can think deep. The trick is to keep differences at bay and play on each other’s strengths to code accurately. After all, two heads are better than one!

Category