S Marks The Spot
To hold a pen is to be at war.
All | About | Agile | Java | Other | Sins | Tech | VCS

20060414 Friday April 14, 2006

Let's Look at the Code

Like many programmers, when I first heard of pair programming (one of the eXtreme Programming practices) I thought “Ewwww!”

Pair programming can be difficult and tiring. We don't do XP in my project and we're not likely to start soon. However, pair programming can be extremely effective in certain cases, such as for teaching and mentoring, for diagnosing obscure and difficult bugs, or working through really hairy code.

But how can you get people to start pair programming if they don't want to? You pretty much can't dictate “henceforth, everyone must start pair programming.” Well, you can dictate, but people won't follow. Or if they follow, they'll do so in a reluctant, grumbling fashion. Not the best way to improve productivity.

Yet I do find pair programming valuable in many circumstances, and people often don't pair program even when it's useful to do so. How to start?

I'm a senior engineer, and engineers on the team often drop by my office to ask questions about how to solve some problem they're working on. It's part of my job. I used to answer questions by drawing on the whiteboard or by waving my hands and describing how I thought a solution would look. More recently, however, I'll say something like “Hmm, well, let's go look at the code.”

I'll then wander over to the engineer's office and ask them to show me what's going on in the code. They'll pull up source files and start showing them to me in an editor. Pretty soon we'll run across some code that's not behaving quite right. We'll talk a little bit about how the code should be behave, and what changes need to be made to fix it, and so forth. I'll say, “Well, why don't you check out the file and we'll make those changes right now?” And we do. And pretty soon, we're pair programming.

Some time ago we had started advocating pair programming in my team, but nobody was really doing it. At one point I used this technique on one of the engineers. At the end our the session, I asked her, “Did you realize we've just been pair programming for the last hour?” The grin on her face was priceless.

So maybe we should pair program but not say we're pair programming. Just say, “Let's look at the code.”

Posted by smarks ( Apr 14 2006, 06:36:31 PM PDT ) Permalink Comments [2]

Comments:

Getting off your butt and walking over to the other person's desk is really important for other reasons, too. It drags you out of your own rut. It confirms that your focus is on helping people. It drastically reduces the chances of mismatch between what each of you is saying and what the other one is hearing. I've been making an effort to do that a lot more over the last couple of months, and I feel much better for it. (Doubtless not coincidentally, I've also been pairing much more, and I also feel much better for that.)

If I'm remembering correctly, in the first Agile toolkit podcast, Bob Martin gives a trio of core practices from which the rest will naturally flow. Pairing isn't one of them; an open office is. Once people get used to talking in close proximity, good things will follow. Something I'd like to try some time...

Posted by David Carlton on April 17, 2006 at 09:50 PM PDT #

David, thanks for the link to the podcast. The "trio" of core practices Martin mentions (short cycles, open plan office, test driven development with automated unit and acceptance tests, planning game) is really perhaps a quintet, depending upon how you count. This makes sense, but it's not much more than a restatement of critical XP practices. There are a few other insights in the podcast that I'll blog about shortly.

Posted by Stuart Marks on April 19, 2006 at 09:54 AM PDT #

Post a Comment:

Comments are closed for this entry.

Archives
Language
Links
Referrers