Pair Programming is a practice which is associated with agile development but is in fact a practice from the Extreme Programming movement. If you are not familiar with pair programming then the idea is two people share a computer, mouse and monitors and pass control back from one person to another as part of the development process.
Woody Zuill has taken this idea in an intersting direction with his practice of mob programming. Some practionioners, including Woody use the idea of a navigator and driver when pair programming. This is where one person drives, and the other person or people say what direction the code show go in. In a pair programming scenario, in practice, the driver also has some input.
Now if you have ever studied the process of writing you will be aware that there are two ‘modes’ the brain works in when writing something, even as simple as a short email. The two modes basically break down into a creative mode and an editing mode. Often cited as the best way to write is to get something down on the page, while not worrying about grammar, spelling and the turn of phrase. This allows you, as the author, to get into flow and get your ideas down. You then go back and look at the piece of writing and in the second mode, edit mode, you’ve guessed it, edit what you have just written. Correct the grammar, spelling and re-working sentences so the whole peice flows better.
Now coding is very much the same. When you code you should first be in creative mode and then go to edit mode and refactor your code. This is partly why TDD is successfull because it gives the coder a better opportunity to get into flow. But what would happen if you could split your brain in two and be in both creative and edit mode at the same time?
This is one aspect of what pair programming can give. Yes, each person in the pair may well learn something different from the other person. And yes the liklihood of mistakes in the design may also go down. But in my opinion it is the ability to be in the two modes simultaneously that can give you speed.
However there is a downside and that is perception. Pair programming still suffers from the perception that if two people are sharing the same keyboard and mouse then only half the work is getting done.
From where I stand I would say that pair programming can work, however there is a lot of debate as to whether the cost of pair programming is worth the benefit? For example there is an excellent analysis by Dave Nicolete on does pair programming work and also some interesting discussion on the Cunningham & Cunningham, Inc. site.
Like many agile practices my personal opinion is that pair programming should be seen as another tool in your coding toolbox. When a hammer is the appropriate tool to use, use it.
Do you pair program? Or maybe you are thinking about pair programming where your work? If so then please leave me a comment as I would love to hear about your experiences.