Page 235 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 11: Coding Process

improves student retention in an information technology major. This topic provides an overview Notes
and history of pair programming followed by a summary of the use of pair programming in
industry and academia. It is also provides insight into the principles that make pair programming
successful, the economics of pair programming, and the challenges in the adoption of pair
programming.

11.3.1 The Driver and Navigator
One of the pair, called the driver, types at the computer or writes down a design. The other
partner, called the navigator, has many jobs. One of these is to observe the work of the driver—
looking for tactical and strategic defects in the driver’s work. Some tactical defects might be
syntax errors, typos, and calling the wrong method. Strategic defects occur when the driver is
headed down the wrong path—what driver and navigator are implementing just would not
accomplish what it needs to accomplish. The navigator is the strategic, longer-range thinker
of the programming pair. Because the navigator is not as intensely involved with the design,
algorithm, code or test, he or she can have a more objective point of view and can better think
strategically about the direction of the work.
Another benefit of pair programming is that the driver and the navigator can think at any time
the situation calls for it. An effective pair programming relationship is very lively. In an effective
pairing relationship, the driver and the navigator continually communicate. Periodically, it is
also very important to switch roles between the driver and the navigator.
Pairing During All Phases of Development

The name of the technique, pair programming can lead people to incorrectly assume that we
should only pair during code development. However, pairing can occur during all phases of the
development process, in pair design, pair debugging, duo testing, and so on. Programmers could
pair up at any time during development, in particular when they are working on something
that is complex.

Draw the incremental life cycle models.

11.3.2 Necessity of Pair Programming

Some people think that having two people sit down to develop one artifact must be a big waste
of resources. Managers are especially concerned about this since they think they will have to
pay two programmers to do the work one could do. Even students are concerned about this
because they think they might have to spend twice as long on their homework. However, some
research results show that these concerns do not materialize.
Higher-quality Code
Pairs developed higher quality code faster with only a minimal increase in total time spent in
coding. For instance, if one student finished a project in ten hours, the pair might work on it
for five and a half hours (for eleven total hours of time between the two). The code produced
by the pairs in the study also passed 15% more of the automated test cases, demonstrating that
the pairs produce code of higher quality.
Enhanced Morale, Teamwork, and Learning

Pair programming offers additional benefits, including the following:
Increased Morale: Pair programmers are happier programmers. Several surveys were taken of pair
programmers in the North Carolina study discussed above. Ninety-two percent of them indicated

LOVELY PROFESSIONAL UNIVERSITY 229