Pair Programming Rules
*Adapted from a text by Robert NoonanPair programming is often described as [Williams 2000]:
a practice in which two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, or test. This method has been demonstrated to improve productivity and the quality of software products.
Students working in pairs are required to abide by the rules given below.
-
Share. "In pair programming, two programmers are assigned to jointly produce one artifact (design, algorithm, code, among others). ... One person is typing or writing [driving], the other is continually reviewing the work [navigating]. ... Both partners own everything." Not only is this an effective learning technique, it is also more productive than splitting a task in two, working on each half separately, and then combining the two.
-
Play fair. It is important to take turns typing or writing [driving], so that the other person gets a chance to review [navigate].
-
Clean up. Defects belong to the pair. Having two sets of eye balls is much better than one.
-
Hold hands and stay together. All programming should be done together; do not create things done alone. The literature of pair programming shows that most defects are traceable to things done singly. It also inhibits learning.
-
Say you're sorry. "Ego-less programming ... is essential for effective pair programming." Do not insist on having things your way or else. Do not get defensive about criticism. Work things out as a pair.
Laurie A. Williams and Robert R. Kessler.
All I really need to know about pair programming I learned in kindergarten.
CACM, 43, 5 (May 2000), pp. 109-114.
Violations of Pair Programming
- Splitting a task in two with each person doing half.
- One person doing all (most of) the work and the other partner putting their name on it, as though the latter had contributed equally.
Possible Sources of Stress to Consider
- Disparity between experience levels.
- Scheduling difficulties.
- Reliability.