Eddie Garmon's Weblog

Pair Programming

Ideal Pair Stations

One of the biggest aspects of eXtreme Programming (XP) that is usually rejected is that of Pair Programming. This usually due to pre-conceived notions by the developers or poor pair station design that does not actively engage both developers. Pre-conceived notions are hard to eliminate, but providing a developer friendly pair environment will help in adoption of pair programming, despite these notions.

The hardest obstacle to overcome is to keep both members of the pair actively engaged during the entire coding session. There are many different approaches that you can take to keep the developers active. Having a manager or coach baby-sit them, requiring driver changes every 10 minutes, or “You must pair” rules only make developers hate the practice of pair programming. In most cases all that is needed is several environmental changes that will facilitate developer engagement and interaction, and improved adoption of the practice.

Get out of the corner.
One of the hardest environments to pair program in is the common office setup with the computer and monitor tucked away in the corner to increase desk space. This creates several problems, as usually only one developer is ever actually engaged in the current coding session. The partner is stuck looking over the code monkeys shoulder, if they are even paying attention to what is being written at all. In most cases, the partner will open the book to appear as if they are looking up something relevant to the current coding task, leaving the monkey to do the work. This usually results in double the work cost for a project, and should be avoided at all costs.

One of the simplest, most effective changes to get both developers active is to replace the corner desk with a standard 6x2 table; folding tables work well. Place the computer in the middle of the table. This allows both developers to sit at the table, to be closer to the action on the monitor, and to easily switch who is driving by only moving the keyboard and mouse. Both developers can always see the monitor, and no one feels as if they are being watched, which is a natural distraction.

Use technology to your advantage.
Once you are out of the corner, use the cheap cost of technology to your advantage. Most computers sold today have at least one USB hub embedded onto the motherboard. This allows the user to easily add more input devices than the standard PS2 keyboard and mouse. Attach a second USB keyboard and mouse. Most modern operating systems, including Windows XP and Windows 2003 Server, support having two active keyboards and mice. Now both partners in the pair can actively drive, and are not prone to the ‘open book and fake pairing syndrome’. A word of caution here, as it does take a little time to fully realize the power developers have when that can change what the other is working on without directed intent, and to overcome their natural tendency to start typing or clicking while their partner is doing so.

Now that both members of the pairs can actively drive, enable them both to more easily see what they are doing. Provide a second monitor and place one in front of each developer. The simplest way of doing this is to buy a video feed splitter and multiplex the output from the computer to both of the monitors. This requires no internal hardware/operating system reconfigurations, and is fairly simple to do. A second way of providing two video feeds is to replace your current video card with one that supports multiple outputs, or adding a second video card. In either case, you need to configure your operating system to mirror the video output to both monitors, so that each pair is seeing the same thing on the screen. Extended desktops can be useful in some pair debugging sessions, but more times than not, you want both developers to see the same thing. As such, setting up the dual video card systems with extended desktops is not recommended.

At this point, both developers in the pair are in front of their own console, and can actively participate in what is happening in the coding session. This not only improves the partners understanding of what is going on, but facilitates the partner’s ability to inject when they have issue with what is being developed.

In Practice
On my last engagement, we experimented with the concepts and practices of XP during a major release. Once that release was over, the team as a whole accepted XP, and we moved to that development style for the next release. This included adoption the pair programming model. Before adopting XP, we had a center room that held four developer cubes, each with corner computers. After several days of fighting the corners, minimal creature space, and the ill comfort of leaning over shoulders, it was time to take action and improve the development experience.



First we disassembled the cubicles, leaving only the desk that was attached to the wall. This took about two hours to disassemble all four cubes. (Total cost, four man hours and a little sweat.) We removed the dividers creating a very open room. This helped to promote discussion between pairs when questions about the existing system arose, or when pairs got stuck on solving the issue at hand. Next we placed the original computer towers on the middle of the desk, and attached a second USB keyboard and mouse. (Total cost, $10 a keyboard, $20 a mouse, per station.) The next step was to add a new monitor and video splitter to each station. We originally had 21” monitors on each of the dev boxes, and decided to add a second 21” for the pair. (Total cost, $250 a monitor, $40 a splitter with cables, per station.) We now had 4 pair stations in the room, and added an extra table out of one of out conference rooms. At a total cost of $320 per station, we now had a very conductive XP pair programming environment.



After only a few weeks of using this new environment, productivity on the project increased, and everyone’s knowledge transfer more than doubled from before when we were all in separate offices and cubes. After a few months of using this environment, it was noticeable that everyone’s overall knowledge of the application had increased beyond what normally would have occurred in the same amount of time in separated environments. This allowed us to have more than the original developer fixing bugs in defined project areas, and enabled feature requests to be implemented in a shorter period of time. After a year of being in this environment, there was no question that we had earned back several times over the initial $1300 we invested to create the ideal pair development environment. Our bug counts for each iteration (two weeks) had reduced about 38% from the pre-pair days, and each successive iteration was seeing less and less new bugs entererd into the bug tracking system.

Increasing the engagement time of each developer is required to successfully adopt the practice of pair programming. This leads to increased knowledge transfer throughout your development team, overall better communication, and more productive coding sessions. And to do so, it can be as simple as changing the environment that pair programmers work in.