What is Pair Programming?
Pair programming is a practice used by developers and software engineers where two programmers work side by side at one computer. One person, “The Driver” writes code whilst the other, “The Navigator” reviews the code as it is typed — the roles are switched frequently. The practice originates from ‘Extreme Programming’ (Beck, 2000) as one of the ‘Key Practices’ of programming. In this post, we will explore the supposed benefits of this collaborative learning technique along with some of the criticisms and downfalls.
What does the science say?
A 2014 study ‘Evaluating Effectiveness of Pair Programming as a Teaching Tool in Programming Courses’ (Faja, 2014) found that when students partook in Pair Programming, their confidence in the quality of their work increased, and they were able to accomplish tasks much faster than they would be working individually. However, this study is conducted within the context of learning and education; it makes sense that a student who is not familiar with programming concepts finds a task easier and faster when working with another student.
In a working environment, however, there is a bottom line to think about. Like with all taught practices, whether or not it is actually used in the real world comes down to economics — is it worth it for the company to roll out a Pair Programming program? Cockburn (2000) dove into the economics of the practice and found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications, and is considered more enjoyable at statistically significant levels.
So, are there any downsides to Pair Programming?
The initial excitement of Pair Programming following the release of ‘Extreme Programming’ came with its criticisms from the community — most notably from McBreen (2003) in the book Questioning Extreme Programming. McBreen even admitted later that they let Pair Programming off easy in this book, following up in a 2010 blog post outlining his grievances with the practice. McBreen argues that pairing makes a developer focus on writing the code, so unless there is time in the day for solo exploration, the team gets a very superficial level of understanding of the code. The discovery of new ideas in times of hyperfocus is not encouraged. Furthermore, another case argued by McBreen is that developers can come to rely too much on the unit tests, assuming that if the tests pass then the code is OK. This is a bi-product of the inherent lack of investigation and scrutiny which comes with pair-programming. The exercise becomes more about making unit tests pass rather than fully understanding the code or improving the solution.
What does the programming community think?
Similar to the previous section, the community is seemingly split on the effectiveness and economics of Pair Programming. Hackernoon makes a great point that draws from the science of learning we addressed previously — Pair Programming makes knowledge transfer so seamless, that onboarding becomes easy. The cost of a pair-programming initiative is somewhat offset by the time saved in not having to put your new hire through weeks-long training. This kind of ‘On the Job’ training gets new hires familiar with the codebase whilst making impactful contributions to the team and workload.
Another benefit Stackify points out is that having new hires Pair Program with the team is a perfect way to build great relationships and rapport right off the bat. It is also a great way to induce code reviews — which can be a difficult feat in a busy office. Code reviews are usually born from necessity rather than in a preemptive effort to avoid future problems or improve knowledge amongst staff. Having somebody not only review the code you have written for accuracy and efficiency but also review your methods of how you came to that conclusion is extremely valuable in a developer's growth and understanding.
From these community posts, it sounds like we’re all in agreement, right? Wrong.
There are plenty of adversaries to Pair Programming — a Reddit post debating this Tech Crunch article is a telling read. The article is extremely anti-pair-programming, but the Reddit post is a nice intermediary. Redditors argue that boundaries need to be set in order to utilize the effectiveness of Pair Programming. It is common for too much time to be spent criticizing and amending code style without ground. Unless a reason can be made for how the code will impact future development and maintenance, then spending time criticizing how the solution was made is time lost. On a similar note, a critique must be weighed against the probability the issue will ever come to fruition in the future. It is easy when Pair Programming to over-analyze the solution by thinking out loud about extreme fringe cases, this can become counterintuitive to the task in hand leading to time wasted and valid ideas scrapped.
There is a theme in the community that Pair Programming can easily become a time-wasting activity, prioritizing high-level criticism is essential in making the task worthwhile — on top of this, it is a good idea to box off an allotted amount of time for the task, to force you to concentrate on the higher priority issues over lower priority style issues.
Conclusion & My Experience
It has become apparent during my research that when Pair Programming works, it is great— but done badly it can become a cumbersome and counterintuitive task within a team. McBreen (2003) makes some great points regarding the surface level understanding which can come with the lack of exploration in Pair Programming, but there are times when it’s appropriate and times when it’s not. For example research, experimental programming, easy bug fixes, and boilerplate code are scenarios where Pair Programming may not be the correct fit. However there is a time and place for the activity — debugging, peer reviews, difficult bug fixes, and deployment are all examples where Pair Programming excels.
I personally found Pair Programming most proficient whilst debugging. Having another set of eyes on your code can give wonderful ‘ah-ha!’ moments that would take you hours to fix. The answer is always glaringly obvious once somebody else points it out to you. However, when I was given an intricate Pair Programming task such as creating a Two-Player math multiplication game from the ground up — I found it difficult to concentrate and fully understand the code we were writing. I came away from that activity believing a prior solo planning session would have gone a long way in fully getting a grasp on the task and solution.
Pair Programming works differently for everybody. Recognizing when it is working for you and setting some ground rules goes a long way. Be sure to pick an allotted amount of time for the task, concentrate on prioritizing high-level criticism and choose scenarios that best fit having a teammate to help.
References
(Site references linked throughout)
Beck, K. (2000). Extreme Programming Explained, MA: Addison-Wesley.
Cockburn, A. (2000). The Costs and Benefits of Pair Programming, Humans and Technology.
Faja, S. (2014). Evaluating Effectiveness of Pair Programming as a Teaching Tool in Programming Courses’, Information Systems Education Journal (ISEDJ)
McBreen, P. (2003). Questioning Extreme Programming. Boston, MA: Addison-Wesley.
