What is pair programming anyway?
One day my boss suggested that we were going to work on a feature together for about 30 minutes. I was still new to software development and I had not heard of an extreme programming technique called pair programming. He said that some development teams had fully adopted it and do it on daily basis. I could not understand how it made sense that two programmers work together everyday on the same workstation. That would definitely lead to wastage of resources as I though that the productivity would be half. Moreover, it seems annoying to always have someone looking over my shoulder the whole day! It is intruding my privacy. However, after the pairing session with my boss and some research about how to pair effectively, my perspective changed completely.
In pair programming, there are two programmers involved, called the driver and the navigator. The driver is the one who does coding and is in control of keyboard at a particular time. The navigator is not actively involved in coding and focuses on thinking about what to do next and and how the task they are doing fits in the general design. The navigator should not do trivial things like checking the missing semicolons when the driver is typing.
Importance of pairing
This arrangement frees the driver to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and gives the navigator an opportunity to consider strategic issues without being distracted with the details of coding. The team therefore creates a higher quality code more quickly than either could produce on their own. Pairing also reinforces good programming habits due to positive peer pressure to perform difficult tasks like continuous testing and design refinement. The flow of work is also better as there is likely to be less interruptions from other people if they see two people working together. In case somebody interrupts, the navigator can handle the noise as the driver continues to code. With pair programming, there is a transfer of skills from senior developers to junior developers as they work together. These include the coding skills, problems solving skills as well as understanding the how to tackle tasks. It reduces the efforts needed to coordinate as the a pair is seen as one programmer which can be seen as roughly halving the efforts by the whole team to collaborate. Pair programming is therefore the first natural step towards team collaboration. Coordination is enhanced further by the natural need to change partners by the team members, ensuring that a members works with as many developer as possible within the team.
How to pair effectively
To reap the benefits of pair programming, there is a need to deliberately pair effectively. Some of the tips of pairing effectively are highlighted below: The pairs should not be decided by the team leader. Pairs should be fluid , forming naturally and shifting through the day. Over time, everyone in the team should have at least paired with every member of the team. This obviously improves team cohesion and leads to spread of knowledge throughout the team. Partners should be switched freely when there is a need for a fresh perspective. This happens especially when a pair is stuck on something leading to no progress. It is a good practice to switch partners several times in a day. Working with different people encourages team collaboration and helps in spreading the skills throughout the team. The partners in the pair should ensure that they sit comfortably to increase the productivity. It is also good for the partners to always converse as they work. For instance, the driver and the navigator should always think out loud to ensure that the partner knows what is going on.
Pitfalls of pair programming
However, there are so many pitfalls that can come with pair programming. Here are some of them: If both programmers are not actively involved in the session, there will be no benefit of the pairing. The worst case outcome of the pairing leads to doubling of costs if one of the programmer, particularly the navigator decides to remain passive throughout the session. This happens because the pair will be doing only the work of one person. Mismatched skills may make some developers treat the session as student/teacher instead of seeing each other as a peer. This hinders collaboration. It is advisable for the senior developer to ask the junior to research on something before the session begins. If communication is ineffective, it will be hard to collaborate well as each developer will just focus on his/her task. This can happen when the driver decides to focus on coding, making the navigator feel like she has been left out. It is encouraged that the driver and the navigator think out loud. This helps a partner to understand the thought process of the other partner and may approve, not approve or ask for clarification. Due to different preferences on tools and keybindings, there may be endless editor wars for example. The teams should overcome this by trying to standardize on the toolset.
Conclusion
If adopted as suggested above, pair programming will lead to production of a higher quality code. Try introducing it gradually to the team, and ensure that the teams members are okay with it, do not force anyone to pair!
