Pair Programming (XP) adds quality to the final result: feature done and quality max.
What happen when a new member enters the team?
How can he understand the code, the big monstruosity the human kind ever built? 
Lots of long sessions of code reading solo … or, maybe, pair programming sessions ?
What if a big part of the team move to a brand new project?
The existing helpdesk team adopt the new baby to let him live long and prosper, despite customers requests.
What if you company buy a small company, so your team inherit a running legacy system that cannot be replaced.
Your team must adopt this system, learn everything about it in order give support and future.
What if this new system doesn’t have the self-explaining code property?
Well, XP tells that refactoring and pair programming add lots of good values to your products…oohhh come on, lets face the reality! 
What about if this new system has less or nothing documentation, or even comments?
This is not so rare in legacy code developed by solo-programmers, where ancient knowledge vanished throught the centuries (IT time speaking). 
A good mix of learning solo and pair programming sessions improve the “human code coverage” metric.
“Pair Programming is not a tutoring session” says a good book
and that’s true but, in situations like these, it’s a very good “pattern” in order to build that “collective ownership” needed to handle quickly and correctly the new system.
Straight from the white book:
The conversational nature of pair programming also enhances the software development process. You quickly learn to talk at may different levels-this code here, code like this elsewhere in the system, development episodes like this in the past, systems like this from years past, the pratices you are using and how they can be made better.
UPDATE: these are my minds at this stage, maybe I’m right, maybe I’m wrong; surely I’ll refactor on next iterations 
Technorati Tags: Agile, XP, Pair Programming
Tags: Agile
