pair programming

A programming practice (in)formally described and preached by eXtreme Programming methodology users.

Programmers work in pairs to create all production code. The idea is that the second programmer provides constant code review for the one who is "driving." If code review is good, then take it to the extreme by doing it all the time.

Ideally, two programmers working together can produce better quality code faster than two of them working alone. I guess this is synergy.

There are also other side benefits like constant mentoring and knowledge sharing. Pair programming also provides better communication in a development team.

The two participants in pair programming are called the driver and the navigator. The driver is working the keyboard and thinking about the immediate task: "Ok, open this file, scroll down to that method, rename this variable." The navigator is, in general, thinking about the bigger picture: "All right, we're applying the bridge pattern, so we're going to have to create this class, and it's going to be responsible for such and such."

One thing I've noticed is that after a day of 6 or 7 hours of focused, concentrated pair programming I feel totally drained, as if I'd worked for 10 hours or so on my own. But you really feel like you've acheived something: quality software, and you know it won't break. You have unit tests for it and your pair kept you honest.

Contrary to popular opinion, the pair is not passive at all, both people working at their full capacity, not being slowed down by getting stuck, since if one of them starts to get stuck, the other may already have the answer and if not, they can switch positions and try to each gain a fresh perspective.

Pair programming has already been noded above, but the decision making as to whether to adopt it fully depends on the wishes of the team. It is certainly not a cure-all and in fact puts constraints on facilities and the IT department (who have to only buy computers that can support dual monitors, for example). It can also affect staffing: odd numbered teams have difficulties every day. Here are various pros and cons regarding making the decision to adopt the above.

Pros and Cons of Pair Programming:

Pros:

• Encourages developers to work together, giving different perspectives on a problem
• Results in effective knowledge transfer between team members, leading in reduced bus numbers, especially for critical tasks
• By its very nature, discourages web surfing and IM usage at work
• Encourages members of the team to check in their work to a central repository, so that one doesn't have to work on a specific computer because changes are not available to all developers at any time.
• Allows for some socialisation
• Allows people with different skill sets to synergize their results.

Cons:

• Close Proximity/Keyboard sharing can transfer illnesses between team members, so the use of hand sanitizers, hand washing and a certain level of hygiene is mandatory
• If the two members in the pair are greatly mismatched in experience, one will slow down the other, resulting in a net LOSS of productivity
• Antisocial or difficult employees will affect the workplace to a far greater degree