Some Thoughts on Pair Programming
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
Two programmers, one computer. To management, it sounds like waste. To Agile mentors, it sounds like the answer. What does it sound like to developers? The answer (as with most things) is “depends”.
I have only been pair programming for a little over a year. Prior to that, the majority of my career has been spent alone in a cube or office.
In 2001 when I started in my first job, we did something like pair programming. Obviously, it was not called that at the time. It also did not look like today’s pair programming. It consisted of me sitting next to a more senior developer while he or she wrote code. I would help dictate requirements and help transpose. It was still two eyes on one screen. This style of work helped me to learn the system, but it didn’t really help me learn to program.
Fast-forward to today. I am in a position that pairs 100 percent of the time. We switch pairs after every two-week iteration. One developer usually takes the keyboard in the morning, and the other takes over in the afternoon. We sit at large tables with a single monitor between us. We each have our own laptops and simply switch the video cable for the monitor. This allows us to set up our own computer to suit our unique needs (plugins, keybindings, etc.). It also allows us the ability to turn away and check emails or text messages on occasion.
After working in this environment, I have seen how well it works to get new hires integrated with the software. I have seen how it helps fresh graduates start learning the “right way”. I think about all of the missed opportunities from my past career with regret.
In addition to the two benefits described above, it is also beneficial on new features or working around critical components. Two sets of eyes are better than one.
However, pair programming is not a silver bullet. I feel that it doesn't work for every company or situation. Production support is one such situation. Oftentimes, tracking down bugs is a hunting mission. Lots of different paths have to be explored to find the bug. Pairing will only get in the way there.
Simple feature enhancements usually do not require a pair. These features are fairly simple and straight-forward. They do not touch critical components. Pairing on these types of features is a waste of time.
In conclusion, I am not advocating NOT pair programming. I advocate the use of it in the correct situations and not just simply applied as a constant practice. I highly recommend doing pull requests prior to integrating any code into the main branch. This will allow a second set of eyes to review code. I also highly recommend writing tests. In my opinion, these add up to more quality than 100 percent pair programming.
 Obviously, there is no one “right way” for everything. But there is usually a lot of predisposed teaching that needs to be undone to most fresh graduates.