Removing Bottlenecks in Pair Programming
There are a lot of articles on what pair programming is, why it is liked and followed by some people and organizations or why not. This post lists some bottlenecks in pair programming and suggested ways to address them.
A lot of organizations embrace pair programming, or pairing for other tasks for the values it adds:
- Two pairs of eyes are better than one, code gets reviewed while being written.
- Catch bugs while you are actively writing code, without waiting for traditional code review.
- Faster ramp up for new members in the team.
- Knowledge sharing of tools, languages and frameworks which improves overall skill of the team quickly.
- Context sharing, work is not stalled if one developer falls sick or absconds.
- Less stress among developers.
In an ideal pairing scenario, there is a story or task with a sufficient understanding on what needs to be done. The pair members are considerably skilled to perform the task. One person takes the keyboard as a driver, writing code. Navigator keeps an eye on the tests, edge cases, suggests improvements in the code and the pair moves forward with some agreements. The members switch roles regularly.
But it seldom happens. People have different level of skill sets, context, and they are socially different. Pair programming as a practice faces different challenges at different times because of these aspects. Lets take a look at some of these.
- Keyboard hogger-passive pair.
With such a pair, one person finds it hard to leave the keyboard, often dragging it back to him/her, while the other is exactly opposite.
In this case it is highly likely that the passive one will wander off, with the former doing majority of the work. The passive member will wake up to the pairing once in a while, ask what is going on, try to catchup. But most often than not, he/she will wander off again. This washes out the benefits that pair programming was supposed to yield.
If you work in a pair programming environment, you have to think carefully if you are one of these personas, and course correct if that is the case. Giving and receiving feedback on how you did as a pair is undoubtedly helpful.
2. The expert-novice pair.
With such a pair, the first one has most of the functional context and/or expertise in language/framework being used. It is very important for the pair to realize that while the expert will be driving it for most of the part and the novice will be gaining the context, the latter still has a role to play in looking for edge cases and other general concepts for programming that can be applied.
In a lot of cases, the experts tends to rush, which might lead to hogger-passive pair situation, and it must be avoided at all costs. It is often helpful to let the novice do the typing part, ensuring that he/she remains involved in the task, and gains as much context as possible.
3. That task needs a spike.
These are tricky situations in my experience, specially if the spikes are technical in nature. The context is loose, no one is a driver, and you need to google search a lot of things before you can start on some work. If you can manage to find value as a pair, that is great.
But you both might get stuck, or both might just be trying to drag the other in your own direction with egos clashing over better solution. In such cases it may be sensible to break off as pair. You can do your research and come back with some concrete points, discuss and agree upon one as a pair. There could be multiple ways of solving a problem and you need to agree on one and start pairing in a driver-navigator mode.
4. The other commitments.
You seldom just code. There are meetings, mails, chats while you are at work. You might have to take an interview on a day. Some team members may need your help at times. While all these things are important, they can put your pairing off if not handled efficiently. You may find yourself in a situation where the cumulative effect of all these things does not let you concentrate on the task you were pairing on.
Considering these as distractions while pairing, the time lost will be double as your pair will have similar commitments. There are times when you look back at your day and realize that you could not even pair for half an hour at one go.
Special mention to chat tools here. The constant stream of messages starts giving a sense that every message is important, and needs to be read and replied to immediately (think of all those slack channels buzzing every minute). If you take a step back and think about it, it really is some sort of communication anti pattern that your team must sort out.
Regarding meetings, recruitment, and other such activities, teams must adhere to core working hours, keeping other meetings out of these hours. While sometimes quick huddles are required in the team, random meetings or long discussions should be discouraged.
If there was an ad-hoc meeting scheduled, after you had planned your day, you should ask yourself or the organizer what is so urgent about it. And move it to next day if possible.
If you need some help from your team mate, just don’t shout out. Believe it or not, it just puts that person off from what they were doing, and if you are too loud, it does the same to others around you as well. Be mindful of what others are doing as well.
This is not a comprehensive list. Every time you feel that pairing is not generating the value it is supposed to, you must talk to your pair and ensure that roles and expectations are clear and are being followed. If that does not solve it for you, escalate the issue. There is no point following it as a ritual.
Developing pair programming skill takes time and patience, but if done right certainly has its advantages that helps your team deliver high quality, useful software with more confidence and less stress on individuals.
