Another view on Pair Programming
First of all, I have just ordered your book and I'm sure it will be an interesting read. I'd like to comment on what you're written here,
There does need to be a back lash against extreme programming, like any fad its only after people have used it and evaluated it, is it fully understood.
Extreme programming isn't a magic bullet, it is however a very powerful tool if you use it correctly in the right way. To put this into perspective,
I have worked for three years now for a development house which has adopted extreme programming whole-sale so I have quite a bit of experience in the methodology.
As this is an article on pair programming I'll stick to that subject not other interesting topics such as when Extreme Programming should be used, after all XP is a
methodology, and like all methodologies there are times when you would or won't want to use XP. For example, you'd never use XP on safety critical systems as it lacks rigor
but you certainly would use it for proof of concept projects.
At our Company we only use Pair programming about 50% of the time. I think this is weakness in your article, any agile method should only be used pragmatically, when it is
going to deliver benefit. Obviously there are occasions when certain pairs or the task itself are not suitable for pair programming. So buy another computer and do it on your
own. There is little point pair programming when the work is very simple and has been done many times before. Performing simple tasks would be your analogy of walking
across town. If the task was to navigate a car across London, then a second map literate pair would be very useful.
Pair programming should be used whenever the task is new, complicated or different, developers may know roughly how to solve it, what design patterns they are
going to use but don't know how its going to hang together. Here developers are implementing designs while they code and this is a very dangerous time. Bad designs produce so many headaches further down
the line, the concept of one developer thinking strategically and one thinking tactically is really true.
When you get onto true 'Voyage of Discovery' projects, then you're into the land of code Spikes. but we're talking pair programming now so I'll stay focussed.
Your hypothetical pairings miss out one very important scenario Expert-Expert. All our best, core code has been built with two of our experts programming together. Two experts together make very few
substantial mistakes and have the ability to design on the fly very elegant pattern oriented code even for 'Voyage of Discovery' category problems. The time saving for architecting that stuff right
is massive, the result is not only code that works, but code that is simple.
Everyone has mentioned it, but learning is critically important too. But interestingly its not just junior staff who needs to learn, its all your developers. By far the most damaging code changes we
have in our company is when one of our bright sparks goes off and rewrites a piece of our core code, then goes off for a week to meetings and customer sites and everyone is left with a major piece of application functionality
they need to learn how to use by looking at the code. (the darker side of refactoring) This isn't as efficient as the task being pair programmed and then its more likely an authority on that new piece of functionality will be around.
The statement that you think one indicator of good developers is that they want to work alone is interesting, IT projects now are larger than any single person, you need a strong, direct, efficient mechanism for
developers to communicate, if not pair programming then what? Of course, other modalities exist but there needs to be something.
One interesting thing Martin Fowler wrote a long time ago, to paraphrase: "I'm a good programmer with great habits". Habits is one thing you can instill into junior developers quickly (with the aid of a heavy stick, hehe)
Any process will take a while to teach people to be better developers, but pair programming quickly teaches people the process better developers use to develop (unit tests, refactoring, design patterns, etc).
As for recruiting Pair programmers, we use Pair programming as part of our interview process, we give people a task during the interview and they sit with our people and write a little code. We haven't had any problems
recruiting developers who want to do pair programming because most people are looking for the chance to do XP (because its sexy... or as sexy as IT gets) and most people want to code better.
Pair Programmer (currently sat on my own)