A metaphor to explain why PairProgramming works so well, and how each person plays a different role.
I think this SurprisingReverse happens when programmers discover what the U.S. Navy already knows -- Not only is it better to have two heads in the cockpit than one, but each head has a different role. LeoScott and I noticed the surprising reverse when we were pair programming, and it worked like RobMee described to you. The front-seater does tactical thinking -- where does that semicolon go. The back-seater does strategic thinking -- what are we going to do next, while acting as a safety backup ("hey, how about lowering the gear/putting a semicolon in there").
Our division of labor didn't happen on purpose. It emerged. I invented this analogy to try to explain why:
In front of the keyboard as well as on the front seat of the fighter, the driver is by necessity in a very tight mental loop, thinking about what to do right now. A state of flow emerges, where the pilot makes many moves instinctively. Good training is what makes each instinctive move the right one. The better the training and the better the pilot can maintain that mental state where the right moves happen automatically, the better the odds of winning. In air combat this tight cycle is necessary because the activity is hard real time. A second's hesitation before making a move can make the difference between getting the shot and getting shot at. In extreme programming, this tight cycle emerges because of NanoIncrements. The code/test cycle is done with very small changes to the code, sometimes just a line or two. When you're only changing a line or two of code, you don't really have to think to debug it when it goes wrong. It's just evident what was wrong, and you fix it -- as if by reflex -- and move on to the next change. The driver very easily gets into a tight, quick loops of reacting to the code. This is an incredibly productive state. Large amounts of working code get written very quickly (compared to other leading brands).
However it is very difficult to maintain this winning mental state and simultaneously think strategically. Air combat schools spend countless hours teaching it. It's not a natural skill -- it's hard to learn. In the cockpit, if you fail to think about the future, you can with perfect reflexes drive your plane into a situation where you are going to lose. And if you only think about the future, you can kill yourself right now. In front of the keyboard, if you fail to think about the future, you can happily flow into a blind alley which you need to back out of before you can continue. Happily, refactoring keeps these mis-steps from being the deadly problem they are in air combat, but wouldn't it be better to have another brain for strategic thinking?
That's why the Navy puts two pilots in the plane. The front seater is now able to get into the state of flow, working on setting up this missile shot or this carrier landing, knowing that the back seater will be helping to watch the sky for bad guys, watching the fuel state, helping to make sure that the checklist got executed, and thinking about what the plane should be doing 10 minutes from now.
I don't mean to imply that the front seater of a US Navy fighter doesn't think about the future, or that the programmer in front of the keyboard never thinks ahead. What I mean is that the same natural division of labor takes place in the cockpit and in front of the computer, for the same reason.
Leo and I think that this analogy describes perfectly how we came to experience the SurprisingReverse. I welcome your input. -- WayneConrad