Palermo's rules for Pairing:
Pair programming is a great way for real-time code review and collaboration. Chances are that the end goal will be reached more quickly by working with a partner when writing software. This might sound counter-intuitive at first if you think that 2 people splitting the work would accomplish the goal faster. What actually happens very often is that, without communication, work is duplicated, or people code is slightly different directions. I'm won't pander to the benefits of pair programming too much, but when pairing, here are my rules:
- Talk while you code. Explain the thought process that is leading you to type what you are typing.
- Play the TDD game. Have one person write a test, then pass the keyboard so that other other person makes the test pass. The person who gets the test to pass decides if he wants to write a test next or pass the keyboard.
- If both programmers aren't on the same page for the task, whiteboard it to form a common understanding.
- Commit the code to source control after each task is completed.
- When working in a team of more than 2, rotate pairs so that knowledge flows.
- If one of the programmers is a clear novice on the task, have him drive first until he's no longer the novice.
- Don't steal the keyboard. If you know of a better way to accomplish a task, explain your thought process so that your partner understands the better way.
- Defer driving. If you are completely comfortable with the code that is about to be written, pass the keyboard to your partner. Writing the code will benefit him more than you.
- Communicate. It's tought, and there will be disagreements. No one has overruling authority. If you haven't convinced the other of your viewpoint, you haven't communicated it effectively. If it's important, then everyone on the team must understand why.
- Communicate.
- Communicate.
Posted
02-20-2006 1:06 PM
by
Jeffrey Palermo