Pair Programming

Extreme Programming (XP) is a new, Agile programming methodology (for constructing and maintaining programs) that is becoming quite popular for medium-size programming projects. XP might be called a sociological-oriented approach to developing software. It breaks with other, more engineering-oriented approaches to developing software, by concentrating on the interactions among clients and programmers and the interactions between programmers and other programmers. In this course we will focus on two major aspects of XP.

The first aspect of XP is testing. In XP, tests are detailed before any code is written, so the programmers will know when coding is finished: when the code passes all the tests. This dovetails nicely with programming via iterated enhancement, because we specify the test that every new phase in the program should pass. Later, we will use driver programs to test classes. In real XP, testing is automated as much as possible; for most of this course, we will perform our tests manually, but we will discuss JUnit, an easy to use system for automated testing.

The second aspect of XP is pair programming. In XP, two programmers must always work together when writing code. One programmer is the "driver": that person is at the keyboard, and is in charge of all changes made to the program. Sitting next to the driver is the "navigator", who observes all the code that is entered, spotting problems, thinking of simplifications, helping with programming style, debuging errors, inventing/verifying tests, and generally helping with the problem solving needed to write programs.

"Pair programming is a dialog between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer... The conversational nature of pair programming also enhances the software development process."
- K. Beck, "Extreme Programming Explained"

Although it may seem that the "stronger" programmer will do all the work, studies show that both programmers can participate and benefit: the weaker one sees how the stronger one thinks and works; and the stronger one, by explaining things to the weaker one, has a sounding board for his/her decisions and ends up with a better understanding of the program. Also, bugs that are confusing to one programmer are often transparent to another. Finally, sometimes one programmer will see a simplification that the other doesn't see. Ultimately, the code they produced together is better, because it has been reviewed by two sets of eyes.

The concept of "pair[not peer!] pressure" has also shown itself to be useful. The term means that each member of the pair is pressured to perform well; at the mundane level, this term can mean that when a time is made to work together, both students show up, on time, and work (if you are working by yourself, it is much easier to come up with an excuse to delay starting work).

In the context of learning programming, pair programming allows two students to collaborate closely (more closely than if they each were working independently). For a long programming session, the students should switch off who is the driver and who is the navigator every hour or so. Because most programming assignments involve multiple programs, another way to approach pair programming is to let each student be a driver for one whole program before changing.

Caution: There are many ways to subvert the learning experience that pair programming can provide.

I'll do the even numbered programming assignments; you do the odd numbered ones.
In a multi-program assignment, you write half the programs by yourself, I'll write half by myself, and we'll hand in both as joint work.
I'm the "stronger" programmer so I'll always drive and let you only navigate.

Sometimes the subversion is unintentional: the stronger student just takes control and doesn't let the weaker student do anything. But since much of the course grade is based on how students perform on in-class programming exams, which they must complete by themselves, students taking shortcuts on programs during the semester will be ill prepared for these exams. If your partner is not participating, or is not letting you participate, please contact me so that we can resolve the problem before irreparable harm is done to both partners.

The following Pair Programming Video introduces pair programming to students via a 10 minute video and discusses a similar list of "do's and don'ts"; also print a copy of the accompanying worksheet. You might also like to view Pair Programming Myths I and Pair Programming Myths II.

During the quarter, on some assignments pair programming will be prohibited, on some -especially the early ones- it will required, on most it will be allowed/optional. Each assignment will indicate what rules are in effect in relation to pair programming.

Final words: this is a great learning technique but it requires some maturity to use it correctly: put in the effort and the rewards will be great.