Pair Programming Smells

Source: Tim Ottinger and Jeff Langr

Just as there are "code smells," there are process smells. Pairing is supposed to be a short-term collaboration between equals. Done well it is a high-energy, enabling process that helps teams to gel and to produce much better code. Done badly, it is a rote process to be dreaded.

Unequal access is typical in today's cubicles when the computer is in the corner. While such an arrangement is wonderful for solo work, try pairing when one partner is forced to sit behind the other. Both pair partners need to be able to reach the keyboard and see the screen equally well. It is also helpful if both can use the installed IDE or editor.

Keyboard domination can happen even when partners have equal access. One developer doesn't allow the other to type, either by verbal or nonverbal clues. Sighing when a partner tries to drive, pulling the keyboard out from under their hands, and the like are hardly partnership-nurturing behaviors.

Pair marriage is the name for the arrangement where a pair of programmers are stuck together for entire days, or entire weeks, or entire projects. A healthy pair programming day will include several changes of partner. In some situations, you may have programmers who prefer to pair together. That's very nice, but they will develop the same point of view and end up making the same mistakes together if they don't break it up from time to time. We switch at least once a day.

Worker/Rester is the situation where one of the pair programs while the other watches youtube or plays games or reads a book. Pair programming is not like a cross-country trip where one of you can sleep while the other drives. The point is that both are actively participating. If one needs a rest, maybe it's time to take a 10 minute break. Or switch partners.

Second Computer is usually indicative of a worker/rester situation where one brought along some entertainment for the time when he's not working. Not working? How is that pair programming?

"Everyone does their own work" is absolutely not the way to foster collaboration. In EDTOW, each developer is responsible for a different piece of work. If they complete programmer A's assignment, then programmer B's work is at risk. By holding them individually accountable for separate work projects, the manager is ensuring that the wise programmer will avoid pairing (even if ordered to do so). Instead, the pair must be responsible for their task. If other programming smells are eliminated, you will find that developers do not use this practice to evade responsibility. Instead, a lazy coworker has trouble finding anyone to pair with. That is an easily detectable situation. 360-degree reviews make it a certainty. B Carlson also found that sharing a story across teams helps to relieve the tail-end QC crunch.

90% of work 90% done shows that everyone is doing their own work (EDTOW) instead of pairing, or else the team is swapping tasks instead of completing one and moving on to the next. Either way, it shows a serious lack of collaboration.

People who can't stand to program together have more than a personality problem. They have a professionalism problem. The team needs to be refactored. It may be that one of them can move to a different team where they don't have personality issues that keep them from doing their work. It may be that they have bad blood everywhere they go, indicating that all the teams may be better off with out them. Counseling or "counseling out" is recommended if the root cause is one bad player. If the team is large enough, it's possible that the two can be kept apart, but allowing and protecting insensitive and offensive players is not a way to build a team. It is a way to build resentment.

Debates lasting more than 10 minutes without producing new code is normal among pair programming newbies. It is nonproductive, annoying, and tedious. The better answer is for one or the other to quit telling and start showing how they want the code to work. Arguing in code is better than arguing about code. You can always undo changes, or perhaps check into the repository or archive the code before the code argument so you can revert unwanted changes.

Pairing is a little scary. Tim confesses to feeling uneasy at the start of each new pairing session. It is possible that one partner knows more than the other (or thinks so) or that there are stylistic differences or different paths to different-but-equally-sufficient results. On the other hand, he confesses that he always learns something and does some of his best teaching in pairing sessions.

One can hate pair programming (at least for a while) or find it uncomfortable (at least at first), but it sure does make the code nice. I suspect that nothing produced by an individual is quite as good as if it were produced by a fresh, actively-engaged pair.