Pair-programming as a dogmatic part of the development process is, IMNSHO, very overrated. Coding standards, simple interfaces, commit policies, etc are far mo

Pair-programming as a dogmatic part of the development process is, IMNSHO, very overrated. Coding standards, simple interfaces, commit policies, etc are far more important. Pair programming is useful for, * Building small but critical pieces of code which everyone interfaces with on some level inside a group (a core plugin API would be a good example) * Knowledge transfer. I use PP extensively to work-in new people and get them comfortable with a codebase, svn commit policy, documentation, etc. (I let them choose the tools, read on for more on that). * Solving short coding problems in a common piece of code. Code review also plays a much more important role than PP. The ability to read, understand and change each others code should just be built into the development process instead of trying to force an artificial level of quality/shared-knowledge via PP. As an example, in my spare time I'm implementing a simple and clean Ruby version of some core functionality that we have in C# and JS (yes, I know, odd combination). A colleague is tracking my commits and implementing the same system in Python (also in his spare time). At any point in the future, someone wanting to implement this in Perl (for example) can just follow the commit changes on this reference implementation. PP is also tricky when you choose to do something other than C# or Java, because in those cases you have a common IDE that's used in the company. If you're doing anything unix-y some people will use emacs (setup their way) and others screen + vim (setup their way). Some poor misguided fools will use Notepad++ on Windows, and while that's fair enough if it works for them, that doesn't help matters any for PP. I'm not dismissing PP, but the XP model just isn't suited for every environment.