Dec 12, 2006
While it does not work equally well for everyone, it works extremely well for most who give it a try.
Pair programming is one of the most unorthodox practices of Extreme Programming and is harder than most to digest for people new to XP. Over the last 4.5 years, having managed dozens of XP projects, I have come to appreciate pair programming a lot, and would like to share some of my observations about this practice.
While adopting pair programming caused our developers to rethink many things, one of the other things it did it also forced the company to buy larger desks. Testers and the PM were OK and got to keep their old desks: you have not heard of pair testing or pair project management (now that would be something else). We also had to rearrange our working space to make sure that all project team members worked in the same room: there is nothing worse than a frustrated developer who has to run from one room to another to switch pairs. We even considered getting special chairs (see picture) but rejected the idea as too extreme (yes, there is such a thing as too extreme, even for an extreme shop like Exigen Services!).
Once the furniture problem was out of the way, we had to deal with, ehr, people. The people who simply didn’t see why they should do this ridiculous thing – sit at the same keyboard with someone else. Some engineers develop an outright aversion to the practice, they simply cannot do it. In fact, I believe the motivations of the objections to pair programming are a very interesting topic in and of itself, and could make for a great article. I won’t spend time on it here, but will just quote an article in Computerworld I once read: “You can't sit any two programmers down at a terminal and expect good results, because it flies in the face of why many people program. Programmers consider themselves masters and artists, and if you have two artists at the same palette, they're going to fight over the brush.”
We never forced anyone to do it, but we have asked people to give it a try. Most of those who did quickly saw the light and joined me in advertising thee practice to the rest of the team by stressing the following benefits:
One of the common objections to pair programming is, “But this is a waste of time! Put each of us in front of the computer, and we will produce twice the amount of code in the same number of hours” Well, on the surface, it does seem like that is exactly the case; but only on the surface. If all you have are small, relatively simple and independent programming tasks, you can actually finish them faster working separately. However, imagine a big, complex project with thousands of mutually connected tasks, plus take into account additional time needed for research, design, coding, debugging, fixing, refactoring, rework… you know what I’m saying? In this situation, surprisingly, pair programming yields equal or better speeds and higher quality of code than the same developers working separately. Most of the times, developers found this argument convincing.
So, how did it work? During the morning standup meeting we defined User Stories and tasks to be completed during the day, and developers split into the pairs. As a project manager, I usually did not assign pairs, the process was self-organized. Factors affecting people’s decisions included developers’ experience in specific areas, knowledge related code, and human compatibility. Sometimes, a technical lead would advise a pair combination, especially when dealing with rookies. If a pair started working on a certain User Story, they worked on it together until it was completed. While we did not strictly enforce pair programming, I believe developers worked in pairs 60-70% of the time. It was interesting to observe how a stronger developer would usually work in pair with a less experienced one. Sometimes though we put two stronger guys (or gals) together – usually to tackle a particularly difficult task, or to facilitate knowledge sharing. Sometimes, we would also put to less experienced programmers in a pair to appreciate their initiative.
Not only do the developers get to share their knowledge of the system in question; they can actually significantly advance their knowledge of a particular technology quite quickly. This is achieved by putting a less experienced engineer in a pair with someone more experienced. Pair programming has helped us tremendously to flatten the learning curve and bring people up to speed much more quickly.
I am not saying that you can do any project with any number of inexperienced developers. On a typical XP team in Exigen Services, we have 7 people (4 developers, 2 testers, and a PM). Actually, just having 2 really experienced developers is enough in most cases to move the project forward with reasonably good speed. Roughly, at least half of your team should be experienced and familiar with the codebase and the technology, while the rest can be less experienced; what they need is the general ability and a desire to learn new things. Pair programming empowers newcomers to show great progress very quickly.
(A note to management: as an added benefit, pair programming enables the company to evaluate an employee’s real skill level in a matter of days, as opposed to weeks and often even months in traditional development.)
As much as we programmers hate exceptions, they are a contestant attribute of real life, and pair programming is no exception to that rule. Pair programming does not work equally well for everyone; in fact, for some people it does not work at all. Sometimes it’s character, sometimes it’s the inertia of habit. In my experience, most often the person to completely reject pair programming is a guru with lots of experience and seniority in the organization, great knowledge and skill, and little or now interest in teaching or training others. Some of these kind of guys were able to work successfully on XP teams, sticking to tasks like DB design or research were pair work is less important. Sometimes they moved to traditional (non-Agile) projects where communication between team members was not emphasized.
Of course, pair programming is optional, but I have seen it work too many times in too many was, and I am sold. I hope I’ve made my case and was able to peak your interest. True, individual programming works fine for many tasks, particularly for:
However, no one can deny that when you leave the office and stop at your favorite bar for a beer or two after a hard day at work (no, we don’t do much overtime – 40 Hour Week, remember?), a drink just feels better when you have good company!