Benefits of Pair Programming

Studies show that one of the most cost effective ways to improve code quality is with code reviews. Code reviews are done after the code is written. Often during code reviews improvements are suggested, but rarely is the code retrofitted to incorporate those suggestions. Pair programming has an advantage over code reviews because the review process is done before or while the code is being written. It is very easy to incorporate suggestions at this time. Also, pairing is generally perceived as less judgemental than formal code reviews.

Pairing can also lead to better software design. Pair programming can be like a Texas Scramble/Best Ball golf tournament, where the best contribution of all involved is taken. The pair has the opportunity to be presented with and discuss various alternatives before proceeding. The pair can think up more alternatives than a solo developer could. This yields improved designs, at the high, medium and low levels.

Pairing gives developers reason and courage for improving the code. When a novice, solo programmer needs to work on code written by an expert they may think there must be valid reasons for why the code is written the way it is. Even if the novice thinks the code needs improvement they lack the expertise to make the change safely. The more likely scenario is the novice will copy the existing coding style in the new code they write.

When the same task is worked on by a pair, the expert can explain to novice that they weren’t really happy with the code in its current state. Even if the expert was satisfied with the code at the time, when working with the novice they can see through their eyes the stumbling points when working on the code. Together the pair can agree on which stumbling points are significant, how they should be solved, and implement those changes safely.

From an economics point of view, pair program has a lower cost of development. Some think that having two developers work on a task will double the person-hours it takes to do the task. Studies show that initial development time is only 15% longer or can even be faster. When you factor in the work required to do hot fixes, the improved quality from pairing always yields a lower total development time in the long term.

The quick development time of the pair often comes from an increased focus. Pairing literally is having another person looking over your shoulder all time. People actively participating in pairing are less likely to be distracted by interruptions (e.g. checking email, mind wandering to unrelated tasks, or blankly staring at the screen for minutes on end). Even related secondary tasks can be blocked out. The person on the keyboard can focus on just banging out the code, while the partner can worry out readability, testability, robustness, user upgrade migration, and other “big picture” issues related to the new code. Working with a pair provides positive pressure to stay on task.

Quick development times can also be attributed to faster debugging times. Having a second set of eyes can help find bugs faster.

Pair Programming creates a learning environment. Team members that are expert in one area will share that knowledge with others on the team. There are various areas of expertise that can be shared:

• Domain – knowledge of the customer’s industry, processes, and systems.
• Model – how we represent that domain knowledge in our code and database objects.
• Code Base – general outline/structure of our code solutions
• Framework – discovery, usage, and contributing to common code (internal and 3^rd party)
• Language – proficiency in the programming language, including coding standards.
• Tooling – Visual Studio, Resharper, DBMSs, test frameworks, source control, scripts

There are many benefits of Pair Learning. It decreases the risk carried by an organization by having only one expert (i.e. low bus number ). Pairing dramatically decreases training time, especially for new employees. Solo wading through documentation or painfully trying to get software to run that you haven’t worked with before can be drastically sped up with having an expert on hand.

The introduction of any new process on an organization will lead to a temporary drop in productivity as the new process is being adopted. This will be true of pair programming. In the being a lot of time will be dedicated learning. Significant time in each pairing session will be for solely raising the team’s bus number. Discussion of coding standards and tooling may be common. Instead of pairing on new code, the session may turn into a review of code that has never been previously reviewed. This is a natural part of introducing pair programming. As bus numbers increase the pairing sessions will shift from learning-based to being focused on quickly writing new, high quality code. And this is where the eventual productivity increase will come from.

Pairing not only leads to learning technical skills, but it also improves soft skills. By practicing in pairing sessions developers learn to communication more effectively. Developers learn negotiation skills, honing the balance between compromise and standing firm. It also improves confidence, which leads to more contributions in larger team meetings.

Having pairing sessions several times a week also has a huge impact on team building. Pairing frequently is far more effective at promoting team building than the odd lunch or “beer and wing” night. Pairing leads to trust amongst the team members where everyone is aware of each other’s capabilities.

Virtually all people that try pair programming state that they enjoy it. Human beings are social animals. Happy developers are very important to the organization. Unhappy developers tend to quit. Hiring and training a new developer costs tens of thousands of dollars each time.