Of all the practices of eXtreme Programming perhaps the most contentious is pair programming. Partly because not everyone likes pair programming, but also to some managers it is counter-intuitive: how can doubling up resources on a task be more efficient?
There is evidence to suggest that not only pair programming more
productive , but the system has more longevity. Through collaborative learning the design improves. My experience with pair programming is that although it is harder work it is more rewarding.
Another aspect that sheds light on why pairing is so effective when done well is some recent psychological research on multitasking: Edward Hallowell has identified a condition which he calls Attention Deficit Trait, or Online Compulsive Disorder. Communication like email and other electronic communication on the desktop can cause a person to feel the need to multitask. Pairing, especially in a dedicated pairing area, prevents this from happening. Email, and communication is done after the pairing session. When pairing, you really are giving 100% to the development task.
Hallowell is an author of a popular psychology book on the subject: Crazy Busy, on the books website are useful links and resources. Also listed are
ten principles for handling modern life: without getting stressed. Pair programming in a dedication pairing area is compatible with most of these. I've tried here to draw some parallels with these principles and indicate why pairing can improve the psychological well-being of the team:
Do what matters most to you:
when pairing, your partner can help you assess priorities in the task at hand. Also help make judgement calls about what is important. Indecision is reduced, as often when one it unsure the other is able to take over.
Create a positive emotional environment:
much of the culture around XP comes from removing the cubical and creating a good working environment. Pairing helps create an environment of trust which helps foster a team environment. Pairs that have paired for some time have a better working relationship.
Find your rhythm:
it is occasionally said against pairing that pairing interrupts the train of thought of the more senior engineer with a lot of comments from someone who is the junior partner. In these situations it is important not to race ahead and loose the least experienced. Mentoring in a pair is definitely a skill, and it is important to remember that it is better to hand on the knowledge to the junior. However, I've been in the situation where the gap it very large. In these situations then training is often needed, or another role found for the struggling developer: where their talents are best used. In the case where the developers are evenly matched pairing can help with rhythm. With XP there are number of rhythms: continuous integration means that periodically checking in, TDD normally advocates test-code-refactor then the problem itself may need solving in a certain way. Pairing up can help with the rhythms of solving a problem by having a pair to keep track of the current state of the problem. The roles of the pair of driver and navigator reflect this.
Invest your time wisely to get maximum return:
Choosing to pair means that your have to set aside the times in which you are pairing. Agreeing with your pair when to take breaks and how long to pair for. This commitment helps using time wisely.
Having a separate pair area improves this. The time programming is psychologically separate and breaks planned better when needed. They are done through mutual agreement.
Identify the sources and control of gemmelsmerch in your environment:
Xp and pairing address these through information radiators and again creating a separate programming environment. Even if there is not a separate environment this having two people on the task helps the focus to remain on the task in hand.
It is possible to delegate within the pair. Swapping the navigator for the driver. Pair swapping is also actively encouraged. If all else fails and the task ends up being more difficult than first thought new tasks can be created and tracked by the process.
Taking time to explain in the pair exactly what the design is and ought to be. Prevents one of the pair racing ahead and hacking the solution together. This practice benefits the team. XP also advocates sustainable pace, when developing concentrate on the task in hand, more is accomplished meaning that tasks get solved in the allotted time. This means that working late and racing ahead (leading to bursty productivity) are not encouraged. Consistent progress towards the goal means projects are easier to plan.
Don't multitask ineffectively:
The necessity to multitask even in solving a problem is reduced, additional tasks that such as the next stage of the design can be handed onto the pair. Other environmental distractions are less able to cause distraction when there is two of you. One of the products of pairing sometimes overlooked is the pair's communication with the rest of the team. The Navigator can field questions about the task from the rest of the team, preventing possible distraction from disrupting the complex design decisions. Other forms of asynchronous communications can be engineered out of the environment.
Discussing the design frees up more time to be more creative.
Some of the practices advocated by XP might not only build better software but be of psychological benifit to the team. Causing individuals to make better more productive use of their time. One of the reasons pairing works is it can help overcome some of the symptoms and problems with isolation.