3 Common Pitfalls of Pair Programming you need to watch out for
For those of us who have worked in software development for a few years, we have a fairly keen sense of what it takes to build high-quality software. In the process, we have also seen our share of challenges when it comes to teamwork and collaboration.
One technique that many teams use to enhance software quality and team performance is XP (Extreme Programming), which is actually a collection of many practices bundled together. One of the most popular practices within XP is “pair programming” where two developers sit side-by-side and work on the same code together on single computer.
Does this sound like it would help build better software? It depends!
Many technical people are not used to working with others, especially when it comes to writing code. I have personally worked with (and managed) many “interesting” individuals who are superb coders but struggle with teamwork. I’m sure you have seen this also at one time or another. So how do we still leverage Pair Programming if we have a team people with very different personalities?
Tip #1 – Don’t force people to work together
In order to apply XP practices for the first time, you need to have assertive individuals as well as open-minded people who are willing to try something new and not be worried about failing or taking a short-term hit on productivity. Hence, it may be best to ask for volunteers to try the pairing approach instead of commanding your team to work in a different way.
Tip #2 – Avoid competition
If you have multiple pairs of developers working together, you may be tempted to compare their performance against each other. Do NOT do this! Help the team get comfortable working in pairs but celebrating successes and monitoring trends for that pair; focus on what is working and what is not, and ask the team to share their ideas on how to make it better.
Tip #3 – Watch for “backseat coder”
When developers work together side-by-side, sometimes the more experienced, more senior developer of the pair ends up doing very little work; he/she may evolve into a “backseat driver” who tells the other developer exactly what to do, what to type. This is not the ideal dynamic that you want to have in a pairing situation. If you observe this happening, you may consider coaching the senior developer and help him/her understand the objective of the pair approach, which is for both individuals to share ideas on design and implementation to achieve a specific outcome.
Pair Programming is not for every team, but there is sufficient data to show that this technique is worth experimenting to see if it may add value for your team. Give it a try and see how it might work!