In many cases, two heads are better than one, however, many managers are known to bristle at the sight of multiple employees commiserating on a task. The immediate thought is that it is more effective and efficient to divide and conquer. However, pair programming – an important aspect of extreme programming – is proving that going at a task single-handedly is not always the best solution.
Doug Wallis, president of Toronto-based Agile, is a specialist in extreme programming, and insists that the divide-and-conquer attitude stems from a misconception about what programming is all about.
“One misunderstanding is that programming is typing,” he said. “Programming is about problem solving, and two people looking at a problem often do better than one.”
The concept behind pair programming is that two programmers sit side by side at a single terminal and bang out code together: one “drives” with the keyboard and the other offers input as a passenger. The successful implementation of this sort of methodology involves a few basics before the job can even begin: egos need to be checked at the door, and coders have to come to the scenario with basic social skills and good hygiene.
“A lot of shops have people who aren’t great communicators or have habits that are kind of quirky – a lot of programmers don’t prefer to wash as often as others. For pair programming to work, people need to work well with others and be comfortable with office etiquette,” Wallis said.
Part of the challenge of pair programming is building the right teams. Pair programmers work in twos within a part of a larger team, and each pair is switched up at the discretion of the project’s leader – the switching can happen as often as several times per day or as infrequently as at the end of a project’s iteration.
According to Chris Rea, technical architect at MONTAGE.DMC in Mississauga, Ont., despite the compatible coding chemistry that some pairs might have, pair programming works best if the teams are frequently shuffled.
“I think you want to strive for just about every team member to work with every other team member,” he said.
Because everyone works in a unique way, different things can be expected from different types of pairings, Wallis said.
“If you have two programmers at equal levels, they really churn through the code, but it’s not always super rewarding for them,” he said.
According to Greg Hutchinson, a senior consultant at Regina’s Attractor’s Consulting Inc., there are more often tangible benefits to pairing up a senior coder with a more junior one.
“A lot of the time, senior resources tend to do things in a far too complicated way. With pair programming, they are often forced to explain what they’re doing to a junior person, and this explanation often results in a simpler solution,” he said.
Wallis agreed that sitting a junior alongside a senior programmer enforces a justification of what is being typed into a keyboard.
“Funny things come out of junior people,” he said. “They often do elegant things by accident.”
He went on to equate programmers to swordsmen. The most dangerous competitor to the best swordsman is not the second best, but the amateur, because rather than follow the rules and predictable movements, the junior comes up with wild things that the expert would have never thought possible, Wallis said.
In Hutchinson’s experience one of the most valuable benefits of pair programming is the level of knowledge transfer.
“Somebody always knows about a hot key or a shortcut that you don’t know about, and with pair programming, this knowledge tends to propagate throughout the team very quickly when the pairs switch up,” he said.
Bryan Zarnett, the coordinator and founder of XP/Agile Toronto, recognizes that part of the success of pair programming is the pressure of working so closely with another individual.
“In pair programming, everybody pushes each other,” he said. “That little bit of push with someone always talking to you not only drives you, but gives you motivation. This way, quality is always maintained.”
Despite these sorts of benefits, Hutchinson admitted that pair programming is still resisted because of the challenges that it presents. Firstly, he said, are the logistics of setting up an adequate pair programming environment. Most desks aren’t set up for two people sitting together in a cubicle, he said. Secondly, pair programming requires a lot of planning including when the pairs are switched, and how tasks are broken down.
His advice to enterprises wanting to experiment with pair programming is to do just that – experiment.
“If you don’t want to jump in with the whole kit and caboodle, start with extreme testing with pair and see if you find a benefit,” he suggested.
