[mp-amz]Proponents of pair programming (“pairing”) claim that it boosts long-term productivity
by substantially improving the quality of the code. But it is fair to say that for a
number of reasons, pairing is by far the most controversial and least universally-embraced
of the agile programmer practices.
All code to be sent into production is created by two people working
together at a single computer. Pair programming increases software quality without
impacting time to deliver. It is counter intuitive, but 2 people working at
a single computer will add as much functionality as two working separately
except that it will be much higher in quality. With increased quality comes
big savings later in the project.
The best way to pair program is to just sit side by side in front of the monitor.
Slide the key board and mouse back and forth. Both programmers concentrate on the
code being written.
Pair Programming Best Practices
- Prepare together for the coding you are going to do so that no misconceptions will be developed during coding.
- Start with a well-defined task before you sit down.
- The task should be something you are confident that you can complete in an hour or two.
- Agree on a solution.
- Decide on a general strategy to tackle the task that you agreed upon.
- You may find it helpful to outline what you plan to do before you begin to code.
- This ensures that you both know what you are working on right now.
3. Rely on your partner. Support your partner.
- One person is the driver and the other person is the observer. When you’re the driver, complete the current small goal as quickly as you can, ignoring larger issues. Trust the observer to be your safety net.
- When you’re the observer, read the code that the driver is writing as he or she writes it. Your job is code review. You should pay total attention, aiming to let nothing get by you. Think about possible bugs, larger issues and ways to simplify or improve the design. Bring up errors and code that you find unreadable right away. Wait until the current small goal is done to bring up larger issues and ideas for design improvement. Jot these later tasks down so the driver can stay focused on the present small task.
- When you’re the observer, don’t dictate the code. The driver should be actively thinking about how to achieve the current task, not just typing passively. And as the observer, you should exploit the fact that you don’t need to invent the small details; you can and should think at a higher level.
4. Talk a lot!
- Say what you are about to do, ask for an implementation idea, ask for a better way to solve the problem at hand, bring up alternative ideas, point out possible inputs that the code doesn’t cover, suggest clearer names, suggest ways to implement the code in smaller steps, etc. When people are pairing well, they are talking back and forth almost non-stop.
5. Sync up frequently.
- Make sure you always know what your partner is doing. If not, sync up again. If you are spending five minutes or more out of sync, you might as well be coding solo, because it’s the frequent re-syncing that creates the synergy of pairing.
6. Switch roles often – at least every half hour