Pair programming, or simply “pairing,” is touted as a way for development teams to improve the quality of the software they produce. When pairing, two developers sit side-by-side at a single workstation and work together on specific programming tasks. The theory is that the practice of pairing promotes constant review: Two sets of eyes watch every line of code that gets added to the system.
In this article, I cover the simple mechanisms of pairing–what to do and what not to do. In a future article, I’ll talk about some of the perceived benefits, costs, and challenges related to pairing. Often, teams don’t achieve these benefits, and instead incur only costs, because they don’t execute the practice well. If you heed the following recommendations, you should start seeing many other intangible benefits from pairing.
Do’s
- Pair in an environment that comfortably accommodates two programmers sitting side by side. Programmers in a pair should be able to freely push the keyboard back and forth between each other. It should be easy and natural for programmers to get together to pair. Offices and cubes often don’t support pair; open workspaces and bullpens do.
- View each person in a pair as being in one of two roles: strategic or tactical. The tactical person is the one at the keyboard, coding the current method. The strategic person is not only reviewing the code as it’s being typed, but is also thinking about the bigger picture. “Where should we go next?” “What needs to be refractored as soon as we’ve added this code?”
- Switch roles several times during a pairing session. In a good pairing session, the keyboard should naturally flow back and forth between the two programmers. Programmers should feel comfortable with asking for the keyboard as well as with pushing it aside when they’re ready to switch.
- Use pairing as an opportunity to help others learn valuable time-saving techniques, including things as simple as using the Ctrl-1 (quick fix) keystroke in Eclipse.
- Try to have someone monitor pairing as a coach, when you first attempt it, to watch for trouble spots.
- Set ground rules for pairing. Agree on what developers can work on when not pairing. Ensure that production code written when not pairing gets reviewed as appropriate, in some other manner (Fagan inspections, for example).
- Openly talk about the successes and problems with pairing as often as necessary–at least every other week. Figure out how to correct any problems that pairing presents.
- Expect a learning curve for pairing. It takes a bit of time to figure out how to work with each and every other developer on your team.
- Consider moving people around in order to create a good team mix, one that’s willing to honestly try pairing.
- Be considerate about accessibility needs (such as the need for special keyboards or magnification). Often this presents a significant challenge for some pairings, but it can sometimes be overcome with a bit of technology or ingenuity.
- Switch pairs often! Not following this “do” is the most common, most fatal mistake you can make when pairing. Few people want to be stuck working with another pair all day or longer. Don’t wait until you’ve completed a task before switching pairs. I recommend switching pairs at least once a day. Many of the true benefits of pairing come about by rotating pairs frequently.
Don’ts
- Force pairing on developers, but then again, don’t avoid it simply because of some initial skepticism or gut reaction. Hold some honest conversations with your development team before embarking on it. Set a trial period of two to four weeks, and ask everyone to hold judgment until this period is complete. Look to discuss and correct problems on a daily basis during this trial.
- View pairing as one person watching, the other person doing. That quickly becomes boring and disengages the person watching, eliminating any real benefit from the practice.
- Force the pairs or determine them ahead of time. The best approach is to let the pairs form and swap naturally.
- Sweat the impact of pairing on estimates, or on the ability of an individual to get their work done. It all comes out in the wash.
- Overdo it. Pairing for six hours a day is plenty. Recommend core hours for the team, hours during which programmers are encouraged to pair.
- Be too overzealous about correct simple typos while in the strategic role. Give your pair an opportunity to correct their own mistakes. Most people recognize when they’ve made a typo.
- Get too smart with “when you don’t need to pair.” Learn how to pair well first before you try to figure out when not to pair.
- Let one person dominate in a pairing session. All programmers should be comfortable with grabbing the keyboard when they want to express some of their thoughts in code.
- Let the pairings stagnate. Make sure that developers are working with all other members on the team
- Give up on pairing without first giving it a fair trial. It will take a week or two for developers to start feeling comfortable with the practice and each other.
I personally resisted pairing when I first learned about the practice. I’ve since seen many benefits from pairing as a programmer on a team and also as an observer of many other teams. Done well, pairing is a fun practice that results in high quality systems and high functioning teams.
I’ve also seen teams attempt pairing, derive few benefits, and then abandon it. Usually the team didn’t follow the above recommendations. Done poorly, or under inappropriate circumstances, pairing can waste significant resources and time.
Pairing isn’t for every team or every individual, but you owe it to your team to at least investigate its potential.
About the Author
Jeff Langr is a veteran software developer with a score and more years
of experience. He’s authored two books and dozens of published articles
on software development, including Agile Java: Crafting Code
With Test-Driven Development (Prentice Hall) in 2005. You can find out more
about Jeff at his site, http://langrsoft.com, or you can contact him directly at jeff@langrsoft.com.
