eXtreme Programming

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, which forms much of the focus of a recent Wired article=. 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!

This entry was posted on Friday, August 22nd, 2003 at 3:00 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

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!

Have your say





Fields in bold are required. Email addresses are never published or distributed.

Some HTML code is allowed:

URIs must be fully qualified (eg: http://www.domainname.com) and all tags must be properly closed.

Line breaks and paragraphs are automatically converted.

Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.