Pair Programming? Why?
What is pair programming?
The best example is one I'll steal from Uncle Bob. If you haven't read this little dialog before, take a moment to do it now. Pair programming is essentially two developers sharing one keyboard and mouse. Both developers work together to write the unit tests and code to make them pass. Often you will switch who has control of the keyboard and mouse. I intricately tie together this practice with Test Driven Development (TDD), because a large amount of the benefit is in the ability for one developer to say, “Hey let me see the keyboard”, and write a unit test which will make the code fail.
Why pair programming?
There are many benefits some obvious and direct others as a side effect. When you have two developers looking at the same code, you have two sets of eyes looking at the code as it is being written. You have a much bigger coverage area of the problem domain, and are less likely to write bugs or miss something. At the same time you are also having a live code review in the context of the code. Also you are getting two developers familiar with the same piece of code, rather than “the dude who wrote all the DAO code.” These benefits alone make pair programming worth it, but there are a few more. Often one developer would get stuck on a difficult problem where two can easily push through.
Some of the indirect benefits are that when someone works alone they are less likely to be working. Honestly, in an 8 hour programming day you might get 4 hours of work. Now a good amount of this is due to distractions, like email, instant messages, random questions, not just slacking off (although some of it is.) When you have two developers sitting at the same computer, it takes a larger amount of force to cause a distraction. If someone is sitting at my desk, I am less likely to look at my email or be drawn away from the work I am working on. You are more likely to get 6 hours or more out of two developers at the same computer with pair programming.
On the job training and cross training is another large benefit. When you pair up a weak developer with a strong developer you will get the weak developer picking up the good practices of the strong developer. Pair up two strong developers, they teach each other the little tricks that make them so effective and they both become more effective. Pair up two weak developers, and you… get a mess for someone to clean up… Don't do that! Have a tester who should learn some development, pair them up with a developer or vice versa. Even a product owner or business person can benefit from pair programming to better understand how the application is being developed.
Does it really work?
In my opinion, yes. I have personally seen the benefits over years of doing development work, practicing pair programming whenever possible.