The February 2005 issue of Java Developer’s Journal has an excellent article on Extreme Programming that is well worth taking the time to read.
(Sorry, the article requires a subscription and password. Hint: A good place to start would be here to see if you qualify for a free subscription. …It’s really not that difficult to qualify; if you didn’t fall asleep during my first sentence and actually have some interest in reading the article at all, you probably qualify.)
The article starts off with a high-level overview explaining exactly what Extreme Programming is. If you haven’t used Extreme Programming before, this is an excellent introduction to it. Following that is the section that gives the article its title: Why Use Extreme Programming? The article explains some of the benefits of using XP rather than other methodologies and then even provides recommendations for how to implement XP in an existing team. This is an excellent guide for a team that is new to XP and really takes the mystery out of the methodology.
One of the big things I like about Extreme Programming is the focus on delivering what the customer actually expects in the software. In my experience, this tends to be one of the first things to get lost along the way: What does the customer want and need from the software? During the implementation of the nuts and bolts of the code, it is easy to focus too intently on the design from a purely programming perspective.
While decisions regarding the scalability or performance of one design option versus another are critical to developing high-quality software, focusing on these concepts without balancing them against the user’s requirements can lead to a project that is extremely fast and super flexible, but doesn’t deliver critical features the user needed. If your software doesn’t provide what the user needs, then no matter how whiz-bang-cool it may seem to you, to them it’s garbage and the portion of their budget allocated to paying you for your efforts suddenly becomes much harder to justify.
In the "intro to XP" portion of the article, the author makes the following statement:
"One of the problems people have with XP is pair programming. This is because it is different."
I agree. …And I disagree. (Gee, Dave. Could you be a little more wishy-washy here?) Obviously, pair programming is a relatively new concept in software development. I’m sure there were isolated uses of it through the years, but I don’t recall any methodology formally advocating it before XP came along. However, I don’t think that the reason people have problems with it is because pair programming is different, but rather because the people are different.
Programming teams have their own personalities. Programmers themselves, obviously, have personalities (just how much can be debated) and a collection of programmers naturally has its own collective personality. Once put in those terms, it becomes quite reasonable to assume that a team can have its own likes and dislikes, completely independent of the preferences of the individuals making up the group. Two individuals can both like the idea of pair programming (or any other aspect of XP, for that matter) and yet, due to seemingly minor differences in the way they each approach it, be unable to participate in pair programming together in any kind of pleasant or effective way. The individuals like it but the team (of two, in this example) collectively does not.
For myself, I tend to favor "pair design" (more on that in a moment) rather than pair programming. Whenever I’ve attempted pair programming in the past, it always seems to go as follows:
Me: <type> <type> <type> <type>
Perry: You missed a semi-colon there.
Me: *sigh* <click> <type> <click> <type> <type> <type>
Perry: You misspelled "main" there.
Me: ARRRGH!!! <POUND> <POUND> <POUND>
Perry: (ow)
On my current development team, we don’t use pair programming for all coding. We tend to use pair design and pair debugging and only use pair programming for special or critical parts of the project.
For us, the pair design approach works much better because it is during the design of the objects and their interactions that the most significant errors or omissions are likely to occur. Once the design is worked out, test-driven development will make sure the individual methods are coded properly. (Also, like many programmers I’ve seen, I tend to suffer from "typist’s stage fright." If someone is watching me type, my typos increase exponentially with time.)
The other common use of pairs on our team is when debugging a particularly tricky defect. If a bug is found and the cause isn’t readily apparent, we’re not shy about asking for a second set of eyes to look at the problem. Sometimes the other person will look at the issue and immediately target the cause. More often, though, somewhere in the discussion of the problem a side question will be asked that opens up a new line of thought or even just the effort of explaining the problem clarifies matters for the original programmer. (It is often said that the best way to learn something is to teach – or prepare to teach – it to someone else. Apparently, explaining a defect qualifies.)
One of the big benefits claimed by supporters of pair programming is the fact that it prevents the programmer from investing their ego into their code and therefore getting their feelings hurt when problems are found and/or changes are suggested. This is based on the assumption that ego investment is a bad thing and I don’t think it necessarily has to be bad.
It's good to have a certain amount of ego invested in your code. Caring about the project and taking pride in your contributions to it seems to improve the overall quality of the efforts. Also, how can the customer have any degree of confidence in a project that the developers themselves don't seem to care about?
The problems that many warn about seem to occur when ego investment leads to defensiveness and stubbornness. Having too much ego invested in your code can make it difficult to deal with the inevitable changes that occur during the development process. When a tester reports a defect, the bug can be taken personally as an insult to one's technical abilities rather than as an opportunity to improve the product before the customer sees (and complains about) it.
Also, having too much ego invested in code can lead to a reluctance to refactor. If a developer has a favorite algorithm or implementation in the project and then finds (or is shown) a better way to do it, they may be hesitant to make the changes. The code could be left in a non-optimal state for sentimental, rather than technical, reasons.
The trick, then, is to invest some - but not too much - ego into your code and this can be accomplished simply through internal discipline on the part of the developer. For many, it may not be necessary to artificially enforce this control externally through the methodology.
Obviously, I’m not that fond of pair programming but I do believe in the rest of Extreme Programming and our team implements it well with positive results. (Despite adamant claims of "All of XP or none of XP – there is no partial XP.") If you look into it for your team – and the article cited at the start of all this is a good source of information on it – you’ll probably find that your projects can benefit from the approach.
Just be sure you don’t take it too far. ;)
[Update: I originally left out a few paragraphs from this rant post talking about ego investment. They've been put back in now. ...As if it needed MORE words.]
