Contents |
by William C. Wake
The first reason pair programming works is that a pair can perform concurrent tactical and strategic work which reduces the overall time to complete a task. There is something about the brain that makes it very difficult to think at a high level at the same time that you are doing a lot of hand-eye coordination. I notice that if I try to think about why I'm typing something or what I should do next my typing speed slows down. On the flip side, if I'm rapidly entering code or working rapidly in an IDE, the quality of my high level thinking suffers a great deal. Pair Programming creates strong synergy by filling in the other roles' weaknesses.
The second reason is potentially a quantum productivity leap and flows from the first reason. There is a great deal of design quality that only manifests when you are working rapidly. If the delay between steps is too long I can't recall the needed information. This point is subtle but very important. Although a process may linearly reduce the time to perform a set of tasks, the quantum increases come when the speed increase allows the information to remain concurrently in memory so that the brain can now suggest dramatic new designs.
The desire to appear competent to one's peers helps one drive toward results. In addition, new technologies are often demanding, and the availability of a partner who can either share knowledge (or at least share your frustration) is very valuable. On the other hand, knowing that you have knowledge to share increases your confidence and self-esteem. Finally, there is a sense of lowered competition: when you both accomplish the same tasks, there are no feelings of being left out or anxiety that someone else just coded more in less time.
Reaping the benefits of pair programming requires one to confront a few inner demons. First, there is the inner critic, the constant chatterbox that relentlessly questions our abilities. For most of us, comments such as "What's wrong with me, why did she see that mistake and I didn't?" are always present in our heads as long as we're breathing. Pair programming asks us to accept our humanity and continue.
The second demon is our unwillingness to talk and to listen. The first principle of XP is communication and being able to communicate our needs to programming partner requires some bravery. Perhaps we need more breaks; perhaps fewer. Maybe we want to drive more. Maybe we need more silence. I've often found a need to say, "I need a moment to absorb what you just said."
Finally, pair programming requires us to be highly aware and discerning of the software, while being very respectful of our partner. Pausing before jumping in with criticisms allows you more time to understand your partner's thinking.
Four hours of pair programming feels like a full day's work. I find the XP process to be intense and exhausting. It is a major mental and psychological challenge.
There is strong feeling of accomplishment that comes from knowing a task was accomplished in less time and of higher quality than could be done solo. The experience is the mental equivalent of the feeling after an exercise session. Pair programming creates a synergy in that we are able to improve our inter-personal skills while delivering superior products.