the power of Pair Programming doesn't lie just on the mechanics of how it is applied, it lies in the mindset of the ones who apply it. Pair Programming works but is not a silver bullet.
If your team's communication is poor Pairing is not going to fix it; fix your communication first.
The driver handles typing, navigating between files, and basic implementation. The navigator, on the other hand, looks at broader concerns and checks for mistakes. Does this method fit with the architecture? Are we potentially duplicating an implementation from elsewhere?
Drivers should:
- Think out loud
- Voice your expectations
- Ask the obvious: "What's next, ah yes we still need to fix that properties file." "Can we commit like this?"
- Give a heads up: “When we have done this we’ll see some trouble in module A, we need to fix that too”. And then trust your navigator to worry about it while you get there as fast as you can.
A good navigator, freed from dealing with the mechanics of driving, should be able to spot those moments and see pitfalls coming from further away than the driver.
Good navigators know when to wait a little bit before pointing out a missing semicolon somewhere, and will do it when there’s a natural pause in the driving.
An experienced navigator is good at communicating intent – the what, not the how - and uses inclusive language (“us” and “we”, rather than “I” or “you”) as much as possible while at it, so the driver is invited to revisit some of the motivations behind intents they might not necessarily agree on.
Navigators should:
- Note opportunities for refactoring
- Keep scope of story small
- Ask for a break after each commit and make sure there is a commit each half hour
- Follow the storyline and stop the driver if it doesn’t make sense
- Actively confirm or reject assumptions
- Ask for arguments if a driver takes a non obvious solution: “Why are you doing that, if we change this property it already works, right?”
- Look for the nearest exit: “If you fix that test now we can do a commit first, the build will be green”
- Think ahead. If the driver gives you a heads up, he might not see a dead end. Think it through for a few seconds and then tell him if you don’t think you’re heading to a solution.
- Find a way out before you get blocked. This is the hardest one. Even if you’re not sure you’re running into a dead end it’s good to keep an eye out for alternative routes to an exit. This will save time when you need to back out of something.
Other possible Navigator duties:
- Do all pre-coding work (moving story, creating branch, etc)
- Pseudocode
- Keep notes on the smurf wiki
- For backend stories, write a cURL to test the endpoint and continues to test throughout the process
- Record demo
- Write tests
- Partner A writes a failing test
- Partner B makes the test pass, refactors code, then writes the next failing test
- Partner A makes the test pass, refactors code, then writes the next failing test
Making time to refactor both code and do testing is the biggest challenge with this pattern.
Be more zealous about small increments as switching driver is not that easy. I’ve tried many ways of giving someone control over your keyboard and they all suck, don’t bother with that. The network latency is going to freak you out in 20 seconds. If you really can’t commit in 30 minutes, it is easy enough to create a patch and send that over, but still it’s going to take much more time than just shoving the keyboard over.
The driver does nothing that the reviewer did not direct them to. ... Whenever the driver requires pitching in the idea, he must handover the system to his partner and then carryout the control from the observer position. This approach completely engages the observer.
The driver does the strategic and tactical thinking, along with the typing. As she does this, she tells the “tourist” about what she’s doing. The tourist rarely intervenes.
Even if you believe to know the "correct answer", never tell the partner what to do, instead, ask if it makes sense or propose an experiment to test something that you have in your mind. [Have the beginner's mind.]
Before doing anything, everyone should agree and state clearly what to do next and why. This will expose discrepancies and conflicts that would have to be handled anyway.
The constant focus on a single task is very important, parallelization of subtasks is not Pair Programming.
Synchronization is an important aspect of pairing. Never lose the sync. If any of the pairs is feeling that the other is doing something that they don’t understand, they should go back and explain again, as many times as necessary. If anyone pretends to understand what is happening, Pair Programming will have no effect at all. It is the responsibility of the one that notices the loss of sync to point it out and suggest a step back to recover.
“Is my pair engaged?” or “Am I engaged with my pair?” usually the person that’s driving will be more engaged, and switching it is one technique to help bring yourself or your pair back into the action.
Kent Beck likes to switch pairs every few hours.
A good indication that it’s time to swap roles, even if for a very short amount of time, is if there are a lot of interruptions becuase the driver is unfamiliar with something.
Basically, everyone
Sharing knowledge is one of the greatest benefits of Pair Programming. When pairing in a team, try to pair with individuals holding more or less business or domain knowledge in that specific task.
It is very important for a developer to start pairing with different roles to understand and learn with their point of view and be able to come up with better ideas to tackle the problems.
When I was in college my house mate had his own business and he needed to get something done. He also developed RSI and his doctor told him to leave the keyboard alone. He was in over his head and I offered to help out on the condition that he’d teach me Smalltalk. I didn’t program a line of Smalltalk in my life and I hadn’t even seen the IDE before. I was by all accounts a pretty crappy developer in general, but we were good friends and I just needed to press the keys I was told. How hard can it be we thought?
The first hour my friend went from explaining the domain and how Smalltalk worked through giving up, cursing through the pain, to yelling key combinations in my ear. Three hours later he was sipping espresso while I implemented a few builder methods. In the afternoon he went to the toilet while I finished a test case. At the end of the day he was drawing on a board and I was implementing what was there while he occasionally gave me instructions on how to name things differently, use the debugger instead of reading the code. It was quite pleasant and I had the feeling I could write Smalltalk code on my own. When I tried alone the next day I was completely lost, but I could do what my navigator wanted without annoying him after just one day of trying.
- Practical Styles of Pair Programming
- Effective Navigation in Pair Programming
- Pair Programming Guide
- Comparing 6 Different Styles
- Promiscuous Pairing and Beginner's Mind
- The Power of Pair Programming Lies in the Execution
- Each of us make notes on what you think the Navigator should do (start by looking at Navigator for the list of things Jason compiled from his reading)
- Make Cody's desk a pairing station similar to Jason's
- Check our assumptions that we know what the Driver should be doing
- Do whatever we can to make it easy for the Navigator to admit they've been spacing out, and then to get back in sync.
- If either person discovers that the pair has fallen out of sync, do something to get back in sync
- Suggest a short break,
- Switch roles, and/or
- Restate what you're currently working on and why