Pair programming is an agile software development technique in which two programmers work together at one workstation and share the same keyboard. One person (Driver) writes the code while the other person (Navigator) reviews it and at the same time thinks about the big picture.
How to do it right
- Understand the requirement well before you start. Spend few minutes and discuss with each other.
- Agree on one small goal at a time.
- Support each other
- If you are a driver, focus on small tasks and quickly complete it avoid bigger issues. Trust navigator to your safety gate.
- If you are a navigator, constantly review the code and think of a big picture. You don’t need to dictate the code.
- Celebrate victory when the task is completed or you resolve a problem.
- Changing roles few times in a day helps (Driver to Navigator and vice versa)
- Encourage pairing. Do not worry about slight productivity loss in beginning. This is something I have seen many teams when new teams are formed as they don’t have experience in the pairing.
- Start with a trial. Do not force individuals to pair. Let them decide who wants to pair with whom. Changing pairs constantly helps.
- Pairing for more than six hours a day is not advisable.
- Individuals should switch driver and navigator role when they get bored.
- The Large monitors and good leg room are essential along with co-location which is absolutely mandatory.
- Trust and support each other. The team culture plays a critical role.
- Improves software quality without impacting time to deliver.
- The focus and energy involved are much higher hence chances of making mistakes reduces significantly.
- The better articulation of complexities and hidden details of coding tasks reduces the human errors.
- The requirement elaboration and definition of done usually be better understood.
- Build trust and help individuals to be better skilled.
- The partners can switch when frustrated or stuck. The work doesn’t get compromised. The change in responsibilities once again adds energy to work.
- New recruits come up to speed more rapidly in a pairing environment.
- From a developer standpoint, pairing is enjoyable and valuable activity. I have seen developers who resisted pairing the first time, eventually loved it and found it to be much really useful in terms of learning, more engagement, better quality and successful careers.
- It’s social skill and it takes a time to do it. The best pair programmers exactly know when to say let’s try your idea first. Do not expect the outcome of pair programming from day one. It takes some time to do it in right way.
- No benefits are expected if both the programmers are not actively engaging themselves. It’s “programming it loud’ methodology” hence it is essential that the driver and navigator constantly communicating. The silence kills the benefits of pairing.
- If the two people have personal challenges, the pairing cannot be forced upon. The trust and mutual understanding between the two people is absolutely necessary
- Experience mismatch is another bigger challenge. The senior programmers often want to have more control and give a little room to junior programmers.
- View pairing as one person watching, the other person doing the actual work. That becomes boring and disengages the person watching, eliminating any real benefit from this practice.
- Pairing should be avoided for very simple tasks or tasks which are very clear and can be done in little time.
- Pairing needs to be done by two. The moment the third person added to it, it cannot be called pairing anymore.
- The co-location is absolutely mandatory. The absence of co-location where the work is shared between two programmers is called sharing over pairing.
- Force the pairs or identify them ahead of time which may not be right in many scenarios. The best approach is to let the pairs form and swap by their own.
- The pair programming is mentoring while it should never be. Programmers often pair with somebody with the goal to learn technology and domain. That is called either as mentoring or knowledge transfer. This should be treated as knowledge transition and expecting less than one person productivity is a fair expectation.
- Two people working on the same story but different tasks individually is considered pairing while IT IS NOT! It is sharing the work but not pairing.
- I have often seen individuals complete half the task and hand that over to another team member in evening sitting in a different country and assume that it’s pairing. This is again sharing of work and comes with extra cost due to unknowns, handoff and understanding each other’s work.
- Doing agile requires pair programming. The reality is Agile manifesto never talks about pair programming.
- The initial resistance of programmers that pairing is not a right thing to do. Most programmers like it when they try it. Others don’t do it right and start believing it’s a waste.
- The pairing would reduce the productivity to half. This is one of the most debated topics. I have personally experienced that when it is done in right way, it improves the overall productivity of more than two people working individually.