Sunday, July 4, 2010

Bad Pairs

Like most people, the first time I heard about pair programming I thought it was a dumb idea. I would have never intentionally paired with anyone, however my project manager pointed out that we were pairing all of the time and did not realize it. Whenever we ran into production problems or one of the programmers on our team was stuck, we would sit together and solve the problem... in pairs.

Nowadays I intentionally pair all of the time and I can say with confidence that it has made me into a better programmer, communicator, and team mate but not all of my experiences have not been pleasurable. I have found that pairing, like many XP practices, is easy to get wrong. Project teams misunderstand and abused this practice in terrible ways.

Inspired by my colleagues @moss and @lgdean who put together a presentation on pairing, I decided it was time to start compiling a list of "pairing smells" that I have experienced over the years:

Pair Stenographer - A driver who has no opinion on the subject. The navigator dictates code while the driver types. The crazy thing is that there are companies out there actively searching to fill this role!
"Pair Programmer is an apprenticeship position whose primary responsibility will be to support one of the company's founders - whom will call the Senior Programmer for this description - in the design and implementation of software products. The Senior Programmer will dictate code in python, C++, or other languages to the Pair Programmer."
If the driver is dictating code, tell them to drive and stop being a jerk. Just let the navigator drive and go get a sandwich.

"We're Lost" - This is when the navigator does not know what is going on or how we got here. As the navigator you should always know where the driver is taking you. If you do not know where you are ask the driver to "pull over" so that you can figure out what the current task is and review the changes in your current change set. Then produce a "map" of where you are headed so that you do not get lost again.

"I don't need directions" - The driver wants to change things ignoring any direction from the navigator. This usually happens because the driver does not respect the navigators programming skill. In this case the best thing for the navigator to do is pull the driver aside and give them direct constructive feedback. Diana Larsen and Ester Derby offer an excellent course where the participants are taught various techniques for providing others with feedback.

Pair Copy Editor - "You misspelled that... You forgot a semi-colon...". Navigators, please be patient and let the IDE, compiler, or test tell the driver what is wrong. The driver is not going to get you both killed if they forgot a semi-colon.

e-mailing, texting, and talking on the phone - It's rude. Excuse yourself and go somewhere else.

Watch me look this up - At times innocuous, but pair researching can be a waist if you're both doing it using one workstation. Split up and perform the search simultaneously. When one of you finds something let the other know.

"What if I want to get a sandwich?" - Not everyone is on the same schedule. If you are hungry or have to take a bio break, do not feel compelled to stay at the workstation. It's OK if someone solos for a while.

"Want to pair in my (cube | office)?" - I cannot tell you the number of times I have declined these invitations. The guest is always at a disadvantage. Level the playing field by either setting up a shared workstation or use remote pairing and share desktops.

Pairing as training tool - I often hear people who advocate pair programming say that it is a great way to train new hires. In practice it is a not effective. Bad pairing is not a substitute for good training. When you hire people train them, otherwise your team may find them to be a burden and it has a poor effect on morale.

That's it for my first list. What "pairing smells" have you caught a whiff of?


Anonymous said...

Literal smells emanating from your pair partner :(

Ariel Valentin said...

oh, that is a good one.

Moss said...

In a session at the Agile conference a couple of years ago, I paired with someone who had a Das Keyboard Ultimate on his laptop. It was pretty impressive as a way of taking that "pair in my cube" effect on the road.

With you on pairing as a training tool. I don't have any hard evidence, but I've noticed pretty consistently that new people seem to learn fastest when they pair with other new people.

Ariel Valentin said...

@Moss I agree. New people are more likely to tolerate each other because they are on a level playing field. That is what I really like about Object Mentors Software Apprenticeship model.