Years ago, I was introduced to the concept of Extreme Programming (XP). One feature of XP is that programmers typically work in pairs or very closely together on code reviews. At the time, I thought this was mostly foolish. Sure, code reviews are helpful, but if the programmers are so good, why do they need to work together like this? Isn’t it a waste of resources? Won’t they be half as productive as they are separately? Over the years, my attitude has shifted, and while I haven’t embraced XP as a full-time methodology, I think there is tremendous value in paired programming.
When I’ve used paired programming, it falls under two main categories. The first is when two people truly are programming together as a team; they will sit at the same desk or share a larger room and collaborate. One will “drive” the work, and the other will do it. The beauty of this approach is that both programmers check the work at the same time, and they will come up with innovative solutions to problems. Often what you see is that one person will have knowledge or information that the other doesn’t, and that information gets shared during this exercise. It is also a great way for a more experienced developer to show a less experienced developer new tricks.
To work like this, you need the right workspace. There should be enough physical room for two people to sit together comfortably. At my office, all of us have 6′ x 8′ cubicles, which is very large for cubicles and provides ample room to sit together. Even better, we have a conference room with a large table and a projector. Another critical component is the ability to talk to each other. Too many offices are set up in a way that talking will be a big distraction to others. While our floor plan is a bit open, we all have headphones to tune out outside noises and when people work in the conference room (it is not a good room for keeping noise in). When we moved into this space, we knew from the beginning that we wanted to make paired programming happen whenever needed, and it has worked out very well for us with this setup. Sometimes the programmers will even be in different offices; GoToMeeting and good headsets for the phone call (I’m partial to the Jabra GN9350 series) lets us work for hours as a team without interruption.
The other way I use paired programming is in deep, intensive code reviews. In these situations, the code is already written, but the person who wrote it walks someone else through it. The conditions are the same as when the work is being done together. This is great for finding bugs in code and verifying that what was done made sense. The advantage of working directly together is that it takes a lot less time from the other person. The disadvantage is that any mistakes that are made are found later on, and fixing them is more costly in terms of wasted time.
When using paired programming, you need the right people. Putting two people together who do not know what they are doing will not yield very good results. Putting a really junior person together with a very senior person will likely not be of much use either; at best, it will be a hands-on training session. While knowledge sharing is an expected and desired outcome of paired programming, you do not want to have a net loss of productivity. However, when you have different experience levels or areas of experience, it will act as a productivity multiplier, not just during the session but going forward as well.
Overall, my experiences with paired programming have been very helpful for my team and me. If you have not tried paired programming, I highly recommend it.
J.Ja
Also read on TechRepublic: Is ‘pair programming’ in your future? and Poll: How do you collaborate with other developers?
Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.
