Page 88 -

3.3 Extreme programming 71

2. Some tests can be very difficult to write incrementally. For example, in a com-
plex user interface, it is often difficult to write unit tests for the code that imple-
ments the ‘display logic’ and workflow between screens.
3. It difficult to judge the completeness of a set of tests. Although you may have a
lot of system tests, your test set may not provide complete coverage. Crucial
parts of the system may not be executed and so remain untested.

Therefore, although a large set of frequently executed tests may give the impres-
sion that the system is complete and correct, this may not be the case. If the tests are
not reviewed and further tests written after development, then undetected bugs may
be delivered in the system release.

3.3.2 Pair programming

Another innovative practice that has been introduced in XP is that programmers
work in pairs to develop the software. They actually sit together at the same worksta-
tion to develop the software. However, the same pairs do not always program
together. Rather, pairs are created dynamically so that all team members work with
each other during the development process.
The use of pair programming has a number of advantages:

1. It supports the idea of collective ownership and responsibility for the system.
This reflects Weinberg’s (1971) idea of egoless programming where the soft-
ware is owned by the team as a whole and individuals are not held responsible
for problems with the code. Instead, the team has collective responsibility for
resolving these problems.
2. It acts as an informal review process because each line of code is looked at by at
least two people. Code inspections and reviews (covered in Chapter 24) are very
successful in discovering a high percentage of software errors. However, they
are time consuming to organize and, typically, introduce delays into the devel-
opment process. Although pair programming is a less formal process that prob-
ably doesn’t find as many errors as code inspections, it is a much cheaper
inspection process than formal program inspections.
3. It helps support refactoring, which is a process of software improvement. The diffi-
culty of implementing this in a normal development environment is that effort in
refactoring is expended for long-term benefit. An individual who practices refac-
toring may be judged to be less efficient than one who simply carries on developing
code. Where pair programming and collective ownership are used, others benefit
immediately from the refactoring so they are likely to support the process.

You might think that pair programming would be less efficient than individual pro-
gramming. In a given time, a pair of developers would produce half as much code as