Pair Programming
Pair programming is a style of programming in which two programmers work collaboratively on one design, algorithm, or piece of code. The intent is that the two partners “act as one”: one person “drives” (has control of the keyboard) and the other “navigates” (reviews and actively questions the code). Traditional pair programming happens with one computer and partners switch roles periodically.
The navigation role is not just to passively watch the driver write code. Their job is to think about design and strategy: where is the development going? is there a potential bug? is there something we should design differently? The navigation role should also not just be dictating code to the driver.
Quick Do’s and Don’ts
DO work together at one computer in driver and navigator roles
DO switch roles periodically, approximately every 30 minutes
DO be an active participant regardless of which role you are in
DO ask for help if debugging between both partners is not going anywhere, but try to resolve it in-group first..
DO surface problems with your partner immediately to give the instructor a chance to correct the situation.
DON’T work side-by-side on different computers and only collaborate when you get stuck. This is called “hybrid” pair programming and it turns out to not be as valuable as “traditional” pair programming.
DON’T divide the work into two parts with each student doing half.
DON’T give commands to your partner without explaining the why behind the what.
DON’T compare your group to other groups. Every group has a different dynamic.
The Benefits of Pair Programming
Below are some direct quotes from several papers about the efficacy of pair programming. The citations are at the bottom, and we recommend you look into them if you aren’t convinced yet.
Use of this practice has been demonstrated to improve productivity and quality of software products. Additionally, based on a survey(Williams 1999) of pair programmers (hereafter referred to as “the pair programming survey”), 100% agreed that they had more confidence in their solution when pair programming than when they program alone. Likewise, 96% agreed that they enjoy their job more than when programming alone
However, most programmers are long conditioned to performing solitary work and often resist the transition to pair programming. Ultimately, most triumphantly make this transition. This purpose of this paper is to aid programmers in becoming effective pair programmers. The transition and on-going success as a pair programmer often involves practicing everyday civility, as written about in Robert Fulghum’s poem above. Each of the poem lines (some adapted with poetic license) will be explored for the inherent lessons related to successful pair programming
An experiment by Temple University Professor Nosek studied 15 full-time, experienced programmers working for 45 minutes on a challenging problem, important to their organization, in their own environment, and with their own equipment. Five worked individually, ten worked collaboratively in five pairs. Conditions and materials used were the same for both the experimental (team) and control (individual) groups. This study provided statistically significant results, using a two-sided t-test. “To the surprise of the managers and participants, all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions.” The groups completed the task 40% more quickly and effectively by producing better algorithms and code in less time. The majority of the programmers were skeptical of the value of collaboration in working on the same problem and thought it would not be an enjoyable process. However, results show collaboration improved both their performance and their enjoyment of the problem solving process (Nosek 1998).
(Williams, Kessler), (Cockburn, Williams)