Pair Programming Tactics

DZone 's Guide to

Pair Programming Tactics

· Agile Zone ·
Free Resource
Many developers have embraced the tactics of pair programming while others have shunned and criticized it, generating controversy over whether or not it's generally a good method for development.  One of the problems is in the broad definition of pair programming.  Stuart Wray, from the Royal School of Signals, recently wrote a paper explaining how to define pair programming and make it successful.  The definition of pair programming has been interpreted differently by many different people.  Some believe that it means two people in the same location, writing a program on the same computer, while others say it involves two programmers working at different levels of abstraction.  There's also the "driver-navigator" method where one person codes and the other reviews and thinks strategically.  Not all attempts at pair programming are successful, but there are several tactics that critics should try before they shun this method.

1. Just Talk
Whether they are programming in pairs or by themselves, developers should always talk or "think out loud."  Self-talk and conversation with another person is beneficial to the speaker and not just the listener.  It forces the speaker to focus on examining their questions and it helps them answer their own question.  The listener can also think more deeply when the speaker talks about their ideas out loud.  Chatting back-and-forth is the primary way of bouncing ideas off one another and sharing knowledge.  It's also very helpful if the two programmers perceive each other as knowledgeable or "experts", because that will cause each person to ask deeper questions and challenge themselves to meet the "expert's" standards.   

2. Two Heads are Better than One
In almost any kind of work, it's hard to catch your own mistakes.  When writing code, you notice your mistakes less because what you notice depends on what you expect to see.  A second pair of eyes will look at your code differently and more often catch your mistakes and offer suggestions.  They will also catch mistakes faster and make development more agile.  One thing to watch however, is the effect of prolonged pairings between the same programmers.  If pairs can rotate their team members, they probably should.  When two people work together for a long time, they start to notice or not notice the same things, which defeats the purpose of having different perspectives.

3. Pair Pressure
Novices (and even experienced programmers sometimes) that do solo programming tend to engage in ineffective practices like code-and-fix.  With code-and-fix, the programmer just tinkers with the code, runs it, and repeats the process.  This will yield unpredictable results and gives no real understanding of the forces at work in the software.  Pair programmers will be less likely to slide into this kind of behavior if they set standards for each other, either implicitly or explicitly.  The subtle pressures of pair programming can help developers kick those bad habits once and for all.

4. Determine Experience, Yours Included
The productivity of one programmer can often be very different from another programmer.  Developers can't predict the difficulty or time requirements that someone can handle until they start working together.  When working with a team of pair programmers, rotation is especially helpful here too.  By comparing yourself to other developers, you can accurately judge their capabilities as well as your own.  The team will also figure out who knows the most about certain things and the team will know where to direct their questions on certain subjects.  One other important part of pair programming is doing it side-by-side.  If two programmers can easily communicate during their sessions and literally point things out on the computer screen, a lot more information can be shared.  Just remember, your screen should be covered in oily finger-marks, otherwise you're not doing it right.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}