Pair Programming is Pair Development

Steve Hayes writes about the transition his team made from pair programming to pair development. I feel this to be an important distinction, so I'll use it as my basis for defending pair programming.

The main argument used against pair programming is a supposed drop in productivity. Some argue against this by trying to show that a) the productivity doesn't drop, b) the resulting quality is much better. I'll try a different line of attack.

What if the concept pair programming is misleading? Let's see the main activities while you're developing (very simplistic picture):

• Requirements analysis, talking to the customer, making sure you understand him.
• Design. Seeking a way to implement the requirements in software.
• Coding. Converting the design into source code.
• Testing. Making sure what you've implemented actually works.