Over a million developers have joined DZone.

Some Thoughts on Pair Programming

DZone's Guide to

Some Thoughts on Pair Programming

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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.
Pair of Pears
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”[1]. 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.

[1] 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.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}