“XP works best for medium-sized teams where a product can be delivered in stages, and where there’s freedom to experiment with some of the more controversial techniques,” author Ron Jeffries said.
Inside the World of Extreme Programming
2003-01-06 General Development 3 Comments
I have never seen pair programming used effectively. Most programmers know that reading others’ code is difficult, so having one person being forced to read the other’s code on the fly while the other is forced to give a play-by-play of what they’re writing is rather time consuming.
Ideally, both programmers should both be relatively proficient and at least on the same level. Pair programming breaks down completely as the lesser programmer nitpicks the greater one to death, while when the lesser programmer is on the keyboard the greater must continually suggest better ways of implementing the given problem.
I’ve been in this very situation, and it’s a very uncomfortable one. Now not only are you dealing with others’ code, but you’re dealing with their feelings. The situation can be further aggrivated by the speed at which you prefer to program. It can be excruciatingly boring watching someone churn out code at a fraction of your normal rate and a fraction of the quality you’d ordinarily produce.
I would personally prefer to see pair programming replaced by highly componentized code combined with peer auditing in groups that are working on related components or components which interact with each other. By breaking the code into small and managable chunks, the peer auditing process is easy, and programmers can gain further insight into the workings of components their code will be working with or using.
Pair programming must have been something devised by the pointy-haired project manager to drive talented employees nuts. Other than that, I do like some of the other things emphasized by XP and “Agile” methods – namely, design patterns.
Also, I think your remedy is spot on – the way to integrate junior programmers with senior programmers is to break things down into managable chunks for them to work on.
“I would rather work on a team of geniuses with no process in place whatsoever than work on a team of mediocre programmers with lots of process in place.”
– Grady Booch
Joint authorship in any content-related field is tricky. It seems to work best when the task can be segmented into chapters or discrete areas of expertise where each person can assert ownership and accept responsibility over a specific piece. But there have been outstanding exceptions, such as Lennon/McCartney (this apparently lasted only a few years before it became a charade) and Watson/Crick (a mentor/student type relationship), just enough to keep the idea alive. I’ve also heard it’s common in pure mathematics.