Friday April 14, 2006 | S Marks The Spot To hold a pen is to be at war. |
|
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]Post a Comment: Comments are closed for this entry. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 #
Posted by Stuart Marks on April 19, 2006 at 09:54 AM PDT #