Pair programming is an Agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer (or navigator), reviews each line of code as it is typed in. The two programmers switch roles frequently. [ Wikipedia ]
An often repeated argument against pair programming is that it consumes double the effort (‘man-hours’) to finish a task (since two persons are involved) than when a single person is working on it. The alternative cited is a review-cycle by one person following the completion of the task by the other.
However, I believe pairing up to work on a goal is more effective than ‘one finishing it and another reviewing it’. The reasons are:
When we pair up, there is a joint ownership of the objective and the task: in other words, a sense of ‘We are doing it together’ as opposed to ‘I am trying to verify or correct what you have done’.
When we pair up, it is not necessary that one person sits idle; there are two brains at work, and one person is at least thinking if not acting on solving the problem.
When we pair up, review automatically happens instead of it being a separate activity.
Pairing is ‘team work in action’ instead of solving problems as individuals – ‘I will do it, and you can tell me if I did it right’ is the mindset when one person does the work and someone else reviews it, whereas pairing is ‘Let us think through the solution so that we can make sure it meets the standards’.
I would go so far as to say that any task – not only software development – can be done effectively by pairing up, because two pairs of eyes are better than one!