Pair programming is a software development technique known for more than 50 years, but it is still considered one of the more controversial practices in software development.
Pair programming is where two programmers work together on a single workstation, sharing a keyboard and a monitor, to write and review code.
But why would you have 2 software developers working on a single machine, sharing a keyboard and monitor, when they can double their productivity by giving them a separate workstation?
In this post, I will show what pair programming can do with productivity and quality compared to working separately. In the last part, I will give you some tips on how to start practicing pair programming in your team.
Does pair programming improve the software quality?
Studies have been done to investigate pair programming with the more traditional individual programming.
One of the studies is from Laurie Ann Williams’s Master’s Thesis. In this study, 30 software developers were divided into two groups working independently or in pairs using pair programming. They were given 4 complex problems for which they had to write a software solution.
The quality of the software was measured by how many test cases their solutions could pass.
When it comes to the quality of the software, the conclusion from this study is clear. The number of passed tests was significantly higher when pair programming was used.
Unfortunately, the study doesn’t show how many test cases would have passed if code review was applied. So, one can only speculate if it would have made a difference to the quality. In my next blog post, I will investigate Code review.
But what about productivity?
The biggest concern I hear from managers and software developers regarding pair programming is that productivity decreases. This is a valid concern. If the productivity per developer should be the same, pair programming should be able to solve the problem in half the time.
In the same study, Laurie Ann Williams measured the average time the two groups used to finish their solution so it was ready for testing.
With pair programming, they used, on average, 30% more time per developer to get the software ready for the test. In this study, the productivity is lower with pair programming compared to working as individuals if we only look at the productivity per developer.
While it may seem counterintuitive, pair programming can lead to faster development times. Two developers working on the same task can complete it more quickly than a single developer working alone. The study showed that, on average, the pair-programmers were 1.4 times faster than individuals.
At the same time, pair programming can help reduce the number of errors and bugs in the code by providing a second set of eyes on the code. The two developers can catch and fix errors before they become more significant problems, leading to rework.
Both of these findings indicate that the time it takes for a team to start working on a feature until it is running in production is shorter compared to having a single developer complete the feature. In other words, the development flow is improved.
Other benefits with Pair Programming?
Pair programming offers several benefits that can help software development teams create high-quality software more efficiently. Some of the key reasons why pair programming is essential include:
- Shared code ownership makes the team more robust for changes in the team structure
- Knowledge sharing: Pair programming provides an opportunity for developers to learn from each other. This knowledge sharing can help improve the overall skills and expertise of the development team.
- Improved job satisfaction and overall confidence in their work. In an online survey of professional pair programmers, 96% stated that they enjoyed their job more than when they programmed alone
How can your team start pair programming?
While there are many benefits with pair programming, it can be difficult to introduce and start using.
In pair programming, focusing on mutual respect, role-switching, shared ownership, and clear communication is crucial. It is also important that team members feel safe getting out of their comfort zone.
That is why psychological safety is a crucial aspect to have before teams can use pair programming. You can read more about what psychological safety is and how to foster psychological safety in my previous blog post here.
If the team doesn’t have psychological safety, they may argue that it is a waste of time and not as efficient as working alone. One way to mitigate this is to establish clearly defined ‘rules’ for the pair programming sessions. This should help address the following.
- Could you clearly define what the goal is before the programming session starts? This could be solving a complex problem, debugging, or knowledge sharing.
- The duration of the pair programming session. I recommend a single session should not take more than 60 minutes.
- Define how often we want to switch roles. This depends on the goal. If the goal is knowledge sharing, you should change roles frequently.
When you start pair programming it is important to
- Practice active listening: When your partner is speaking, actively listen and engage with their ideas. This can help build trust and ensure both partners feel heard and valued.
- Practice empathy: Try to put yourself in your partner’s shoes and understand their perspective. This can help to build a strong working relationship and foster collaboration.
- Define roles: Decide who will be the “driver” and the “navigator”. The driver is responsible for typing the code, while the navigator reviews the code and provides feedback.
- Take turns: Make sure that you take turns driving and navigating. This helps ensure that both partners have an opportunity to contribute and learn from each other.
- Evaluate your results: After your pair programming session, take some time to evaluate your results. Did you achieve your goals? What worked well for you, and what could be improved? Use this feedback to inform future pair programming sessions.
Conclusion
In conclusion, pair programming is essential for software development teams to consider. It offers many benefits, including improved code quality, reduced errors and bugs, faster development times, and knowledge sharing. To make pair programming effective, it’s essential to focus on clear communication, mutual respect, role-switching, shared ownership, and continuous integration. Software development teams can enhance their productivity by following these key elements and creating better software.
What about Code Review?
Code review is another technique to help improve the software quality. It is a well-established practice in both open-source and proprietary software domains. It is not seen as controversial as Pair programming; today, most teams have code review as a mandatory step in the development pipeline.
But does it affect the software quality, and what makes a code review good or bad?
In my next blog post, I will investigate whether Code review improves software quality.
I hope you found this helpful and start pair programming in your team.
I would love to hear your experience and thoughts on Pair programming. Please feel free to share this post and use the comment section below.
