TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Pair programming is just what it sounds like -- all programming should be done by pairs of programmers working so closely together that one can pick up and/or modify the work of the other at any time.
Agile developers maintain that pair programmers working together are far more productive over the long haul than two programmers working independently. They maintain that by working in tandem, the design of each part of the code is made more clear and easier to comprehend and that, by working in pairs, individuals learn better habits and produce more than they would on their own.
The pair programming approach institutionalizes the practice of code reviews. Each day, each pair programmer must understand all of the code that he or she is responsible for no matter which partner writes it. Agile development maintains that the result is better, producing tighter code that is easier to understand. Used in conjunction with test-first development, pair programming speeds the development process by forcing both programmers to use the same (or at least a common) design strategy.
Pair programming in an agile development or XP environment creates an atmosphere where people know more because they are involved more. According to Beck, "If two people pair in the morning, in the afternoon they might easily be paired with other folks. If you have responsibility for a task that is unfamiliar to you, you might ask someone with recent experience to pair with you. More often, anyone on the team will do as a partner" [1].
Pair programming is knowledge management par excellence. By making sure that for every function there are two people who completely understand what is going on, there is far less reliance on one key individual who might leave, get sick, or otherwise become unavailable.
Agile . since Jun 23 . Index . DOCs TOP TOC
"In XP, everybody takes responsibility for the whole system," Beck says [1]. In agile development, the central product of the organization -- the software -- is owned by the group. Instead of individual programs being more or less exclusive property of one individual from concept through turnover to maintenance, the entire set of code is the property of everyone in the group. Anyone can look at any piece of code and can, within the boundaries of pair programming, change anything as well.