Pairing is a practice Thoughtworks follows as a part of the software development process. It involves two people working on any significant development task. The call whether a given task is significant or not is taken by the team.
Quite recently, there was an interesting argument in the team debating whether paring as a practise is good or not. I fear the question was not a great one as it led into some subjective opinions on the benefits of paring.
I think the answer to the question is very context specific. A decent way to approach this topic is to look at what people find to be the benefits of pairing and analyze whether they apply to the task at hand.
The most helpful aspects of pairing
Explanation leads to clarity
The need to explain to someone what you are thinking is a great way to keep oneself co-ordinated at all times. Explanation forces one to think through what they are upto and streamlines the thought process of the driver.
The brain is a contexutal machine. Any decision taken by an individual is influenced by their knowledge as well as the set of decisions that they have taken since they started out on a task ( near past ). The second person is there to identify when the driver is in this mode and gently point it out to him/her.
Some people on the team have more context on the task at hand than others. This happend naturally and since code is a collective responsibility, pairing is a great way to bring the team into sync. It is also a good way to share best practices in the team
Things that do not help a pairing session
Style <Pedantic> arguments
In this case, the second person should come up with a failing test case for the section code that they think is poorly styled. If they are unable to, the first person gets veto on the style they choose. Another alternative could be to use a standard style checker like jslint.
Another project uses this “whatever”
People sometimes use libraries just because some other projects they have worked on used them. This is a poor argument and as in the above example, the pair should talk in terms of test cases to clarify the argument.
The driver of the story usually stops talking when they are stuck with a problem. This leaves the navigator out of loop. This defeats the very first purpose of pairing “Explanation leads to clarity”. In a good pairing session, the navigator should always be aware of the question that the driver is searching the answer for and it is the responsibility of the driver to make this happen.
Difficulties aside, pairing is a good way to improve team work, If only the navigator appreciates the programming style and the perspectives of the driver and the driver asks for an opinion on the perspectives of the navigator at regular points in time. In pairing, the driver gets the final say and the navigator pitches in with her thoughts when asked for.
Quote for the day,
“that would be true if the hardest part of programming was typing” – Martin Fowler on “Pair-Programming halves the productivity of developers“