As I’ve matured as a pair programmer in an agile environment, I’ve been able to first hand experience some of the ways to be a bad partner and a good partner when pair programming. One of my major problems was I had a tendency to either hog the keyboard, or I would do what I like to call Backseat Driving: you let your partner drive, but you dictate exactly what they need to type. A typical example (in the most extreme sense) of this might be something along these lines:

Driver:(Looks at test case of seemingly random assertions) So what do we need to do to make this test case pass?

Navigator:Well, let’s get started. Go to the Duplicator class, to line 328. Now, see where it does the string comparison? Type STRING DOT value of … parenthesis…. no, open parenthesis… id number, no the n in number is upper cased… closing parenthesis. Now, add a semicolon.

Driver:(Types) Now what?

Navigator:Call method oogleBoogle in the class SnaglePop and pass the new variable we got by converting the idNumber to a string to it.

Driver:Why are we doing that?

Navigator:That doesn’t matter now, we need to get this done. Now open up…

It’s probably pretty obvious that this pair programming session is going to go downhill fast.

The driver in this example isn’t a driver at all… rather, they’ve become a mindless scribe for the navigator to dictate code to, and the navigator is really driving by proxy.. Backseat Driving if you will. ;)

The navigator in this example thinks he/she knows what is needed to complete the story. They know the system, the architecture, and perhaps the overall goal. However, since they have reduced their peer’s value to nothing but a scribe, huge benefits are forfeited. The driver might have a different perspective that allows deeper insight in what is being accomplished. If the driver in this case is a novice who doesn’t know the system well, they don’t learn much… because honestly, if someone was to dictate Greek to a person to write, they wouldn’t understand a word of it. In all probability, the code will get written slower and would turn out the same as if the navigator had written it solo.

This scenario will also cause much grief and frustration to the navigator as well. After all, since they are now simply dictating what they would be writing, it will be much slower as I previously stated. The same code written solo would probably take 10 minutes, but dictating it could very well stretch it out to an hour (or two)! This can be worse when the navigator feels the story is so small that it “could just be done in a couple minutes”.

So, what is the solution? What do you do when you are the expert in a novice/expert pairing? The underlying goal of pair programming is that it is a two way process… two minds working together as one. If the novice doesn’t know much about the domain or the system being created, they need to learn. In this case, a Navigator should act as a mentor who guides them to learn and understand more.

For example, a good professor doesn’t give his students the answers… he guides them and makes them think about the problems being solved. He gives them a small concrete example, and presents them with problems to exercise their mental abilities to take the concrete solution, abstract it, and apply it to similar problems. I am reminded of my introductory computer science course when I was struggling with my second assignment in the lab and asked for help with precision in C++. He came over, glanced at my code, and simply stated “Think about it.” and walked away. Although my younger and reckless self was compelled to say “Think about this!” and make a rude gesture, I contained myself and looked through my book a bit, played around with some methods for floating point precision, and figured it out.

An ideal navigator in a novice/expert pair writes a test case for partner to make it pass, sprinkling hints on what needs to be done and coaches them, helping the novice learn the domain and the system through hands on experience and discovery. Along the way, they should describe things as much as possible, but keep it abstract as well so they understand the WHY of the code in the current system. Rather than simply show the solution, mention related methods, go hunting through API documentation, or give a related example.

But it doesn’t end there. Although a good navigator is like a good professor, it’s not an accurate comparison. Although the novice may not have experience with the specific domain or the language, there are all kinds of value they can contribute through their knowledge, experience, and ideas. The navigator should listen as much as possible, and let the driver try things out. If a navigator doesn’t think his partner’s solution is good, he should still say “O.K. Lets try it and see if it works.” And if it does work, great! If it can be improved upon, give advice. If it doesn’t work… oh well. Throw it out and start over. ;)

By avoiding backseat driving and letting the novice learn on their own (with some help), the expert plays a pivotal role in bringing them up and making them an expert faster. By sticking to doing backseat driving when pairing, the expert has doomed the novice to be a novice forever, and that is quite a disaster.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!


This entry was posted on Wednesday, March 14th, 2007 at 1:35 pm and is filed under Agile Software Development, Test Driven Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.