I’ve been interested in XP for a while now. Whilst many of the rules outlined in XP have always made perfect sense to me (simple design, frequent unit testing), the one that really made me sceptical was the notion of “Pair Programming(Extreme Rules – Pair Programming)”:http://www.extremeprogramming.org/rules/pair.html, which forms much of the focus of a recent “Wired article(Wired – The New X-Men)”:http://www.wired.com/wired/archive/11.09/xmen.html?pg=1&topic=&topic_set=. For the uninitiated, pair programming has two programmers working at the same desk – one programmer ‘drives’ whilst the other watches. The idea is that they can bounce ideas of each other, and while the coder doing the actual typing can be quite focused on a single line, the other can pick up simple mistakes such as missing semi-colons and the like. The net result is that despite the apparent upfront loss in productivity bugs occur less frequently, and when they do appear they are fixed more quickly.
Although the practice adds 15 percent per programmer to the time it takes to complete a task, the lost productivity is offset by having fewer bugs to fix. “Pre-XP,” says Kevin Yu, “an eight-hour debugging session wasn’t unusual. With XP we spend about half an hour.” Meanwhile, 90 percent of the 41 coders in the study enjoyed working together more than alone, and almost all were “more confident in their solutions.”
My main reservation concerning Pair Programming is the issue of finding someone compatible to work with – I often find it frustrating to try and explain my ideas to people who take longer to understand the concepts being discussed than I do. Likewise trying to reign the enthusiasm of a colleague who completely understands how their one line obfuscated beyond all recognition Perl script works long enough to work out whats going on can really make a dent in my patience. That said maybe I should follow Kent Beck’s (the father of XP programming) advice:
“Extreme programming is an emotional experience,” he maintains. “When you feel it, you understand.” Then he adds a typically cheeky metaphor. “Talking about XP and trying it are two different things – like reading The Joy of Sex versus losing your virginity.”
Perhaps when it comes to looking for my next job XP should be on my “would like to have” list along with reasonable working hours, time for training and decent pay!
magpiebrain 
2 Responses to “eXtreme Programming”
Yes, pair programming is one of those things that has such a high probability of being horrendous. And really, it’s just unrealistic to use it 100% of the time. Some times, you need a good hour or two of silent concentration to get something done, and it’s usually easier to just do it, and then have a code review than to belabour every semicolon.
There’s nothing more frustrating than trying to get your ideas down in code with someone interrupting you with variable name misspellings or other syntax problems. I think it’s a useful tool when you have a particular tricky problem to solve, but I think that code reviews can work just as well (and have been shown to work well in 100s of studies), and pair programming really can’t work 8 hours a day.
One of the main sticks used to bash XP with seems to be the idea that it promotes lazy programming – it doesn’t promote the idea of code reviews. Personally I think if pair programming does work (and to be honest I’ve yet to see any large scale studies to prove this either way) the need for code reviews beyond the use of automated code conformance tools such as checkstyle can legitimately be removed altogether. I’ve always hated code reviews – its the task that has to be carried out by a competent programmer but can be mind-numbingly boring. Design reviews are certainly required – but it would be nice if we could believe the hype surrounding XP as it would remove a lot of the tedium associated with programming!