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: Tere are many ways to subvert the learning experience that pair programming can provide.
During the semester, 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.