Reading Time: 4 minutes

What is pair programming? Simply put pair programming is when two developers are working (coding) together. Pair programming (sometimes referred to as peer programming) is an agile software development technique in which two programmers work as a pair together on one workstation (one computer, screen, keyboard and mouse).

If done correctly, pair programming and swapping will give you constant code reviews as well as knowledge sharing and give an opportunity for discussion and optimum design.

Developer who writes code is usually called the “driver”, while the other developer who reviews each line of code as it is typed in is called the “observer” or “navigator”. During review, developer that oversees or the observer considers strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This gives the driver a freedom to focus all of his or her attention on completing the current task, using the observer as a safety net and guide.

One thing pair programming is not is mentoring. It is expected that the programmers swap roles from time to time.

Pair programming increases the cost (man-hours) required to deliver the code compared to developers working individually. Usually cited best-case estimates of 15% overhead is claimed for systematic pairing, relative to individual work. But this overhead is compensated by gains in code quality and with higher quality you will save time in bug and error fixing and refactoring code later.

For some pair programming and pair swapping is the optimum solution because not only will everyone in the team have their eyes on the code, it’s constantly being reviewed and improved as people communicate and question what is being done. This also means that issues are raised in a much faster manner and not later after developer completed his task. Developer don’t have to wait until month after he started working on a task that someone gives him a negative feedback on what he’s done. If done correctly, pair programming and swapping will give you constant code reviews as well as knowledge sharing and give an opportunity for discussion and optimum design.

 

Pair programming advantages

 
As we wrote earlier pair programming increases the cost required to complete a task or feature compared to developers working individually, so let’s take a look at some of advantages of pair programming:

• Learning and better team knowledge – knowledge is constantly shared between developers who work together, from tips on programming language rules to overall design skill. In “promiscuous pairing”, each developer communicates and works with all the other team members rather than pairing only with one partner, which causes knowledge of the system to spread throughout the whole team.
• Better transfer of skills – this way junior developers can learn a lot from senior colleagues; they can pick up some techniques or broader skills from more experienced team members.
• Higher code quality – pair programming can produce better and safer code. Pair programming increases code (and software) quality and with increased quality comes big savings later in the project (for example IBM reported spending about “$250 million repairing and reinstalling fixes to 30,000 customer-reported problems”). “Programming out loud” leads to clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys.
• Design quality – pair programming increases design quality as developers must negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single developer alone might do thus significantly improves the design quality of the program as it reduces the chances of selecting a poor method.
• Improved resilience to interruptions – when one member of the pair is interrupted, the other can remain focused on the task and can assist in regaining focus afterwards.

 

Pitfalls

 
And now let’s cover some pitfalls of pair programming:

• Engagement – both pair members must be actively engaged with the task, otherwise no benefit can be expected
• Cost – a simplistic but often raised objection is that pairing “doubles costs”; that is a misconception based on equating programming with typing – however, one should be aware that this is the worst-case outcome of poorly applied pairing. If done correctly pair programming can save time and money – higher code quality will save you time in bug and error fixing and refactoring code later.
• Relationship issues – pair programming cannot be forced upon people especially if relationship issues are getting in the way

 

Pairing variations

 
For the end of this post let’s go through some pairing variations:

• Senior-senior (expert-expert) – this pairing variation can result in highest productivity and bring great results but it can yield little insights into new ways to solve a problem as both parties are unlikely to question established practices
• Senior-junior (expert-novice) – this kind of pairing creates many opportunities for the senior to mentor junior developer. This pairing can also introduce new ideas, as the novice is more likely to question established practices. The expert, now required to explain established practices, is also more likely to question them. However, in this pairing, an intimidated novice may passively “watch the master” and hesitate to participate meaningfully.
• Junior-junior (novice-novice) – probably will produce better results than two junior developers programming independently but it’s generally discouraged