ICS H21 • UC IRVINE • DAVID G. KAY • FALL 2007
Pair Programming Guidelines
Two heads are better than one, according to an old saying. This even applies to writing programs: A pair of programmers (working as described here) nearly always beats the stereotypical solitary loner. The pair produces more high-quality code in less time, by far more than two-to-one.
In pair programming, two programmers share one computer. One is the "driver," who controls the keyboard and mouse. The other is the "navigator," who observes, asks questions, suggests solutions, and thinks about slightly longer-term strategies. The two programmers switch roles frequently—every 15 minutes would be a good interval for us, though that's flexible. Even the activities of the driver and navigator are flexible (except for who does the typing); the goal is to work collaboratively, each partner assisting the other as needed, to produce the best joint result possible. It is not pair programming if one person does all the work or if the partners just split up the work and each does half independently.
That's the basic idea: Spend your time in the scheduled labs working with your partner, one of you as driver and the other as navigator, switching regularly. You may need to arrange other times to meet, beyond the scheduled lab sections. We expect everyone to be as flexible and professional as possible in arranging those times as necessary; if your schedule is highly constrained, explore possible outside meeting times with your prospective partners before you commit to the partnership.
You may enjoy reading this paper about pair programming: All I Really Need to Know About Pair Programming I Learned in Kindergarten, by Laurie A. Williams and Robert R. Kessler (Communications of the ACM, May 2000). [Alternate link]
What about individual differences? People new to pair programming often ask what happens if the members of the pair have different abilities. Actually, that is true of any pair of people in the world, probably even including identical twins. The differences may be great or small, one member may have more strengths than the other, but this is exactly like most real-world working situations. Part of accomplishing a task is to get the most out of each member and make each member stronger and more productive on subsequent tasks.
A clearly stronger partner may feel frustrated or slowed down by the other partner, but the stronger partner still benefits from the teamwork in many ways: The other partner's requests for clarification often point out flaws in the approach or solution, the teamwork skills gained have great value in the job market, and the exercise of providing a clear explanation solidifies and deepens the explainer's own understanding.
The less strong partner may feel that questions hold the other partner back or that there is no benefit to participating actively, but pair programming studies show that paired work is consistently better than work the stronger partner does individually. It is part of each partner's job to understand the whole task; that means asking questions when necessary and answering them when possible.
You will choose a different partner for every assignment, so your partners' skill levels are certain to vary from week to week. Still, when you have a choice, you should try to pick a partner whose skill level is close to your own. This won't always be possible, and it's sometimes hard to compare skill levels at all, but we find that pairs are most productive when the partners are at about the same level.
How does this affect my grade? Of course the expectation in ICS H21 is that everyone will get a grade in the A range. Participation in pair programming won't be the cause of any low grades. (Failure to participate fully and cooperatively, on the other hand, could be a problem.)
On assignments that specify pair programming, each pair will submit one solution, marked with both partners' names. (For electronic submissions via Checkmate, just one member of the pair should submit the solution, which should still contain both partners' names; we'll keep track of who's in what pair, so long as you keep us informed of your pairings in the first place.) Each pair will receive a single score on the assignment.
Also, for each paired assignment, each student individually will submit a brief partner evaluation form, administered electronically, which will ask these questions: Did your partner come to the scheduled meetings on time and ready to work? Did your partner read the assignment and preparatory materials before coming to the scheduled meetings, showing up wither with specific questions or ready to contribute? Did your partner cooperatively follow the pair programming model (rotating roles of driver and navigator, questioning and making observations as the navigator)? Did your partner contribute fully, fairly, and actively, to the best of his or her ability, to the completion of the lab assignment? Was your partner's participation professional and cooperative overall?
Filling out the evaluation is required of each student for each assignment; forgetting the evaluation won't help your grade. We haven't yet determined exactly how the evaluations will be factored into assignment scores or grades: We hope and expect that everyone's responses will be positive, in which case it won't make much difference, but we will be looking for recurring negative evaluations.
It may be instructive to read a selection of students' partner evaluation comments from a previous course; they give a picture of what good partnerships are like (and a few disasters, too).
Additional information: Pair programming is one aspect of the trendily-named programming methodology Extreme Programming. A search for "pair programming" or "extreme programming" on the Web will yield many references.