In XP, all significant coding is done in pairs of programmers. Such a pair has available only one computer for programming and therefore one screen, one keyboard and one mouse. The person currently typing is also referred to "the driver" and the other person is referred to "the navigator".
Best suited is a simple rectangular desk (see picture), where two persons can easily sit side by side.
Actual programming follows a simple scheme:
The test cases are implemented best by using any of the xUnit tools, such as JUnit.
As only one person - namely the driver - can actually type, the navigator automatically assumes a broader perspective. While the driver is typing, the navigator reads what is being typed, and he can detect many of typical coding errors right away, such as typos, wrong variable names, even non-adherence to coding standards. This is useful in particular when using a programming language that requires a compile run such as C++. The number of Compile-Link-Cycles can be reduced a lot.
The navigator has also the task of looking at the system from10,000 feet altitude. This helps putting the task, which is currently implemented, in the correct context. In particular, the navigator may make a note about additional test cases that need to be added in order to cover additional scenarios.
While implementing an accessor class for a database table the pair learns that test cases for the referential integrity are not available. Instead of deviating from the orginal goal (implementing the accessor class), the navigator simply makes a note on a new task card. The missing piece is taken care of, and the pair can again focus on the orginal task.
Finally, pair programming supports learning. The partners can learn from each other, but they can also conduct experiments, such as a refactoring they have never done before. Or the beginner learns from the experienced; then the knowledge gap within the team is reduced. Pair programming therefore is a mean to also support the team to become a learning organisation.
In a very large project, on which I had worked in a previous life, one of the subsystems was responsible for the access to the database. As it was a new database system, there was none on the team, who had sufficient knowledge about it. Instead of sending an engineer to a training, we hired a consultant of the vendor for longer time period. This consultant worked paired with several engineers in the team to work on the database subsystem.
As a result, we had two advantages: a) we ended up to have several engineers on our team with knowledge about the database system and b) the consultant learned a lot about our system, which enabled him to do a much better job.
© Copyright 2001-2002 by Manfred Lange, All rights reserved. Terms of use.
Last change: