June 24, 2008

Just Another Glance at Pair Programming

I've always had issues with pair programming. It's not that I disagree with the value claims that people associate with it. I just have personal issues with it. Here are some of the things that have bothered me:
  • Watching someone else use a computer is like fingernails on a chalk board. I know I'm not perfect but seeing how other people get things done with the mouse and keyboard gets my egometer running and I just want to push them out of the way screaming "IF YOU CAN'T DO IT RIGHT DON'T DO IT AT ALL", but honestly... it's not about the right way to do things, it's about the way I do things.
  • Staying focused while navigating is an uphill battle. I'm used to working alone. I'm also used to thinking with my fingers attached to the keyboard. I've always had a hard time being the navigator for too long. I just have a tendency to get bored.
  • Having someone else tell me how to spell my variables names is punishable by death. I don't care if you think the variable should be fooBo when I type fooBO, next time you drive you can change it yourself.
  • Some of the old reasoning behind pairing is obsolete with the use of powerful IDEs like Eclipse, Intelli-J, and others. I don't need someone telling me I missed a semi-colon at the end of a line because eclipse does that for me.
Honestly I have to admit that some of those things are petty and just personal quirks. At the end of the day I have to think about my motivations and just maybe those things shouldn't be that big of a deal (as long as I didn't strangle someone). Other things may require a little understanding of what's really going on when two people truly, productively pair.

What is the point? I'm not going to dig into any text books or even reference wikipedia on this. This is just me stating things from the perspective of a lowly developer.

Pair programming helps keep individuals on track. When I work alone it's too easy to take that personal phone call or do some web surfing (yeah, even tracking down technical, java related web info has to be considered personal surfing). Pair programming increases the quality of code. It's not about missing semicolons or mispelled variables anymore (thanks Eclipse), it's all about checking in code that is clean and efficient and easy to maintain. When you have more than one person working on code it's much harder to make stupid mistakes. Yeah, I said stupid. And we all make those mistakes from time to time. Copy/paste mistakes. Unneccesary else mistakes. So many things that are too easy to do and really easy to overlook will more than likely be caught by a pair of programmers than a Han Solo cowboy coder.

What about staying engaged and focused? I do have a problem with that some. But I recently did some pairing in a way I hadn't thought of before. Once we understood the task at hand my pair wrote the first unit test (yes, we wrote the test first), then when it ran and failed he slid me the keyboard and told me to implement the code to fix the test. I did, then I wrote the next unit test which failed and he got to implement the solution... that was the fastest day of work I think I've ever had. I was very impressed. Personal conversations were cut to a minimum and we both stayed focused on the task at hand since we were both implementing the code in tandem.

I'm not saying that everyone should pair all the time, but I don't think it's a bad idea to do it a little more than you may be doing it already. Every programmer's goal should come down to delivering clean, quality, bug free code. I think pairing will definitely help you in achieving that goal.

Until next time
Les

2 comments:

Jason said...

Good post Les. Forrest and I also found it worked well to do the test + slide keyboard pairing. I notice I'm really really bad about sparking up non work related conversations with my pair when I feel the task the driver is working on is pretty simple. However when I know the keyboard is coming my way it helps me stay a little more engaged.

bubba said...

I was surpised you didn't mention the keyboard issue. I guess it isn't much of an issue.

I believe the 'sliding the keyboard' bit with 'fix a test, write a broken one' was the way we did it in one of our JUG meetings. There was a lot of audience participation.

Everyone at the meeting got a chance to drive and navigate. The only thing I didn't enjoy about the experience was the mac keyboard.