The problems we just described must all be watched for and quickly fixed before they lead to other problems. This is a lot of problems associated with one XP practice, all waiting to slip and catch the unwary coach, who must be especially vigilant.
Pair programming should be a beneficial practice, but its problems are much more acute because (as we discussed in Chapter 3) so much else in XP relies so heavily on its correct and consistent execution throughout the project.
We examine why pair programming s problems are particularly dangerous in XP in Chapter 3.
FANGS | A Pair of Fangs
And it s about the coach remaining super-vigilant throughout the project. If any one of these risks manifests , the circle of snakes is yet again in danger of unraveling. And, of course, if one programmer gets a cold, everybody gets a cold! |
More about pair programming and the common cold in the Camp Regretestskiy sidebar in Chapter 8.
SOLUTION | Pair Programming Defanged The beneficial aspects of pair programming (improved code-level design, knowledge sharing via improved communication, sense of team spirit, and so forth) can be achieved without the negative aspects (high-maintenance practice, potential for incompatible pairing that surfaces every time the pairs rotate, overkill for simple tasks, and so forth) by not mandating its use, but instead encouraging that programmers simply pair up for complex tasks. This can be achieved by following a process that doesn t rely heavily on pair programming. By spending more time on up-front design ”and by making this a team process (which XP does to an extent through the use of collaborative design sessions) ”most of the key design decisions will have been made by the time the team begins writing production code. Written documentation (possibly in the form of a project Wiki) also lessens the need for pair programming and colocated teams . |
We cover XP s approach to documentation in Chapter 7.