Nick Carroll

Hah, I knew someone would throw the navigator role at me. It maybe just a personal thing, but I certainly don’t buy into the navigator role at all. I’m sure someone that liked to hog the keyboard came up with that one.

My esteemed colleague Mark rebutted my post stating that pair programming is not about equal keyboard time, and went on to describe a case where it is perfectly alright to spend more time driving when there is a difference in experience in the pairs. A mighty good example, but really, how does his story about working with a more experienced developer trump my story about working with a more experienced developer?

Besides my thoughts on sharing the keyboard should not be taken too literally. I was not promoting equal keyboard time. I was promoting equal opportunity for both pairs to contribute, regardless of experience. Using a chess clock allows the person that has been “navigating” too long to say “look mate you have been driving for too long and here is the quantitative data to prove it”.

It sounds like Mark’s experienced pair told him how to solve the problem at hand, whereas my experienced pair taught me the thought process of going about solving the problem. This was done by having to implement code to pass my pair’s test, and to test my understanding of what was going on I had to write a test to keep the momentum going.

I don’t see the benefit where I have to write a test and then make the test that I wrote pass. Which is what happens when you hog the keyboard. The code that you produce becomes a self-fulfilling prophecy. Why not make your pair more useful by engaging her in your thought process too, by seeing if they will make your test pass the way you think it should pass? If there is a difference, then that is a good thing. That person thought of something you did not. Or your test simply wasn’t as good as you thought it would be.

A more experienced person can always steer you in the right direction with a good test. In my story, my experienced pair did just that, and if we were using a clock at the time it would show that I would have spent more time at the keyboard. I have since learned a few tricks, and I’m sure now the chess clock will indicate a more balanced reading.

Allowing one person to utilise the keyboard more than the other because of experience is flawed. If the person driving is the more experienced then forget about the less experienced pair navigating. When have you seen a less experienced developer try to influence the thoughts of the more experienced developer? More often than not the less experienced pair gets shut down the moment they pipe up, and the pair continues on with the vision of the more experienced developer that is driving. This is the classic surgeon model of software development, and it has been criticised for its lack of knowledge sharing.

If on the other hand both pairs have an equal opportunity of influencing the other through code, then the process of churning out code becomes a more engaging one for both people. If I were to give a name for this style of pair programming, then I would call it the Sudbury model of pair programming, named after the Sudbury model of education, which promotes a democratic structure for learning which is experiential based.

I have also been told in my last post that I should deliberately take control of the keyboard for extended periods of time, as this will make me a better pair. I’m sorry but how does this benefit either pair? Are you even aware of the average attention span of a human being? Why do you think that the Roads and Traffic Authority (RTA) advise you to rotate drivers every two hours? Or that class times are limited to 50 minutes? Or that stand ups should only last a few minutes. Or that a micro-sleep kills in seconds? The mind cannot stay focused on a particular task for long periods of time without some form of stimulus. The same goes for watching someone code for extensive periods.

I have also been told that the pair should play an “active” part by holding the vision for the work being done and doing the strategic thinking. What is the strategic thinking that you have to do during development? You should have already done the strategic thinking before you even started the story. The strategic thinking occurs when you are sizing up the story, and writing technical tasks that you think will need to happen in order to complete the story. If you are doing your strategic thinking during development then maybe your story is too big and can be broken down further.

Pair programming should be more like chess. Each person has to think a few moves ahead. The more experienced developer is capable of thinking several more moves ahead than the inexperienced developer, and when it is their turn they are able to lead the other down a path in discrete steps. When my pair has the keyboard I am thinking about the next test to write, possibly the next couple. Then when I get the keyboard I get to solve my pair’s test, then immediately move on to writing one of my tests for my pair to work on. This is how I like to work, and I shouldn’t need to rely on a chess clock to work this way. The chess clock is simply a tool for exposing the rocks and making it glaringly clear that the conversation has been one sided for too long.

Finally, hogging the keyboard is bad when you are working with someone that has never pair programmed before. They will never see the benefits of it as they will walk away from the experience feeling less productive. Or feel that they are not worthy enough to touch the keyboard. Constantly swapping the keyboard between pairs is more inclusive and allows for dialogue. Hogging the keyboard on the other hand is more of a monologue that trumpets “this is how you do it…”. Engaging the client developer and treating them as an equal goes a long way with relationship building.

[EDIT] Mark does a better job of explaining how to make a test pass quickly and why it is a good thing. My idea of using a chess clock was aimed to keep this in the minds of developers during a pair programming session.