Pair programming

You’re not serious, you must be thinking to yourself. Why on earth would I think that I have something new to say about pair programming that hasn’t been already said in the long years it’s been common practice in the software industry?

It may well be that I have nothing new to say, but pair programming is not as well spread as one might think. In the more established, larger and stale organizations it is still considered to be a waste of valuable resources. And anyway, the experience of creating code together is different for each individual and each pair.

For the past two week I’ve been working on some code we’re writing and Arik has been babysitting me. In the pair programming slang he’d be called my copilot, but a babysitter is a much more accurate description. Like most developers I’m somewhat of a creative person with a serious tendency to get tangled in something that seems interesting to me and is not necessarily the most important thing to do. This happens to me quite often when I code, think or both and when I try to stop myself from drifting off the task at hand I find myself being irritated and much less productive. On the other hand, when I let myself run wild with the “fun” stuff, days can pass without me contributing something concrete to what we are trying to accomplish a Tuzig.

And so, I need a babysitter.

When Arik is sitting next to me, watching my every keystroke and following my every thought, I can keep my focus without being frustrated. We’ve been working to create a skinned UI using Python and wxPython which is not an easy thing to accomplish. As we were trying to make the damn thing work the way we wanted, I started thinking how nice it might be to create a complete wxPython-based framework that will have full skinning support with alpha blending and all the bells and whisles. I’ve described my thoughts to Arik and drew some simple sketches on a piece of paper to further clarify my monumental goal. He listened carefully to what I had to say and then said “Yeah, but that’s going to take a couple of weeks at least and won’t get us anywhere near where we want to go with our product”. He was right of course and if I were in his place I’d’ve seen the same thing. I’ve copiloted for some developers in the past and I’ve done a good job of it, but when you’re into it and the code is streaming from your brain onto the screen it’s hard to stop and think about the effectiveness of what you’re doing.

Pair programming works if the pairing is done correctly. Extreme Programming says that pair partners should be switched often (more than once each day) and there have been some discussion as to when such a switch should be made. But my experience taught me that it isn’t trivial to find someone who your can pair well with and even when you do, it takes time to get accustomed to each other’s style. One thing I find crucial to good pair programming is relative speed of thought and coding of the pilot and the babysitter. When the pilot’s fingers aren’t generating code at the speed the babysitter feels comfortable with, he can quickly get frustrated and lose focus. When the pilot thinks faster then the babysitter, he needs to stop his flow of code-thought from time to time to explain things to the copilot. And so I feel that the best match is a fast coder for a pilot and a fast thinker for the babysitter. That last sentence implies that not only it is counter productive to switch partners, it might even be counter productive to switch roles in the pair if the matching is done correctly. You can take this even further – if you feel the need to switch roles or change partners, it means you haven’t chosen the right partner for you.

The pair-compatibility is such an important thing that it might be wise to hire and fire people in pairs.

I don’t think that is all that possible though.

Comments are closed.