Pair Programming Benefits, Part 2 – “The Rest”

May 21st, 2013 Martin Andrew Habich,   (email the author)

This entry is part 2 of 2 in the series Pair Programming

When last we spoke, I discussed some of the pleasant discoveries that I had in my initial pair programming outings.  In this post, I’d like to share some of the pain points I experienced, my thoughts on mitigating them, and some additional thoughts on when pair programming might be more or less appropriate.

Brief context: my first experience with pairing comprised about two weeks of regular, all-day pairing.  Following that, my partner and I spent some time addressing defects and code reviews (both separate and together).  After a few days of Sprint wrap-up and preparation, we proceeded to work on a smaller abstract infrastructure work item for a few days.  Finally, once we hit some larger and more straightforward work, we went back to working in parallel (read: separate).

Two Heads Are Better Than One, but Only in Some Respects

  1. Being as we were relatively new to pair programming, it was initially awkward to figure out a system for doing things like checking our respective e-mails throughout the day without disrupting the process. I feel as though this could be alleviated by becoming more experienced as pair programmers, thereby establishing a rapport and rhythm for incorporating such distractions.
  2. Related to the above, it was mentioned that the fact that we were pairing made other developers on our team more reticent to communicate with us. One factor is that they felt bad “disturbing” the driver, feeling as though this would result in the other programmer sitting around “doing nothing”.  Also, the navigator often would not be checking communications regularly throughout the day.  Lack of communication is, generally speaking, not a goal of development.  And yes, that last sentence was, generally speaking, tongue-in-cheek.
  3. I moved around less when I was driving than I usually do. This is bad for all of the usual health-related reasons, but like #1, can probably be alleviated through practice.  When I code on my own, I try to either get on my feet once per half hour, or work standing for a few hours at a time using a laptop stand.  This might just be related to setting up the pair’s work space appropriately.  While navigating, this wasn’t an issue.
  4. There is definitely a slight tendency towards groupthink if you have two developers with coincident perspectives. As you may have surmised, the types of developers who decide to pair program without instruction can also tend to do other fun things inside a code base.  By “fun”, I mean the sorts of things others might call ”non-standard”, “unintuitive”, or “controversial”.
  5. Riffing off of #4, when our code hit our group’s standard code review phase, there were still plenty of things we missed, especially in the areas in which neither of us are particularly strong or focused.  For example, different developers within our group having varying levels of focus on code formatting, commenting, framework consistency, UI testing, unit testing, test case preparation, etc.
  6. In retrospect, I feel like we missed a few spots where code comments would have been in order.  Probably a symptom of working with someone else who understood everything you were doing at the time.  A little bit of awareness and discipline should take care of that.
  7. Pairing for eight hours a day could be stressful.  As I mentioned last time, this isn’t necessarily an accepted best practice anyway. We took a full, relaxing lunch each day, which was a big help to this end.

Pair Programming Wasn’t Exactly Like the Books Said It Would Be!

My experience with pair programming deviated from the “published norms” in a few other ways that I thought were significant.

  1. Many references on pair programming indicate that the driver’s job is to focus on “tactical” aspects of coding, while the navigator’s job is to focus on the “strategic” aspects. Our process did not reflect this in any way, shape, or form. It was purely collaborative, with all of the minute-by-minute problems being discussed out loud. Perhaps there were times whilst navigating that I was spaced out, considering a solution to a problem, while the driver was busy wrangling getters and setters…but I hardly noticed it as such.
  2. Sliding the keyboard between the two programmers – I think this happened maybe three times a week, tops. It was rare to be unable to express a thought vocally. Perhaps a symptom of my partner’s prowess.

Thoughts on When to Pair

My limited pair programming experience brought me many new perspectives that I had not even considered prior to trying it.

  1. Working on a large, complex task made pair programming worth it. I agree with all of the literature which states that there is little to no benefit to pairing on perfunctory tasks…which makes sense.  Ben Northrop, who has more than a few good thoughts, has also made the great point that often individuals spawn the greatest creativity.  There is value in distinguishing complex, highly technical tasks from creative, highly abstract tasks.  Although, even in the latter case, it’s likely that a good bout of pairing is in order after the initial spark has been kindled.
  2. Personalities definitely play into the success of the pair. In my limited exposure to such topics, I’d generally identify both myself and my recent partner as extroverted, low-key personalities. When trying to solve a particular code challenge, I found that my partner was often pushing me to use my idea, while I was in turn arguing that we should be using his idea. This is a lower tension resolution than in the inverse situation. Also, obviously, the fact that we don’t mind constant dialogue was a big boon.
  3. Per #2, I’m not inclined to suggest that everyone on my team should be forced to try pairing as a rule.  I certainly wouldn’t mind if they try.

Closing Remarks

Due to the heightened, sustained focus that I experienced and pairing’s benefits with regards to complex problem solving tasks, I’m pretty sure that we broke even in terms of man-hours-to-deliver.  I wish I had a scientific measure for this, but I don’t.  In addition, I certainly reaped extensive rewards of knowledge dissemination and code quality.  Per the above, this is probably not applicable for all pairs nor for all work items.

You can definitely practice pair programming.  Working with a particular partner over time will see reduced benefits of knowledge dissemination, and possibly quality, but will increase gelling as well as skill in the more tactical aspects of pairing.

I hope to try more pairing in the future, and with a wide range of other programmers, but I don’t expect that I’ll be forcing the practice on myself.  I’m going to let the opportunities find me.  However, my final word – this was one of the most fun and most instructive exercises I’ve undertaken in a long time.

Thanks for reading!!!

Be Sociable, Share!

Entry Filed under: Uncategorized

6 Comments Add your own

  • 1. Pair Programming Benefits&hellip  |  May 21st, 2013 at 10:04 pm

    [...] environment and some of my positive takeaways in this blog post, and then provide a separate post (Part 2) to exposit some of the downsides, some input from fellow non-pairing developers on my team, and [...]

  • 2. Patrick Bresnahan  |  May 22nd, 2013 at 2:50 pm

    This is a great read on pair programming and it’s implicit pros and cons. I’ve been surprised that a platform hasn’t risen up to take pair programming to a level where two are actively editing and working on the same project from both of their computers. And if such a thing exists, why it hasn’t become commonplace.

    The above theory is possibly not viable by some of the things you’ve brought up here. It depends on trusting and being on the same wavelength as your partner. If you’d have issues working well in pair programming, it would only be exacerbated by an active synchronous tool.

  • 3. Jorge Lee  |  May 22nd, 2013 at 10:13 pm

    Interesting post, I think I had a completely difference experience compared to yours because I learned to pair with people who are used with pairing. Here are some things that I learned “right”:

    - You must take breaks. Preferably walk away from your desk. If you do (and you should do) TDD and frequent commits then you have good checkpoints to take a break, e.g.: when tests are green, after the commit, the story is dev complete, etc.
    - Use your breaks to check emails
    - Rotate pairs. The knowledge should be shared across the team and not only two people
    - Have two keyboards and two mouses especially if both devs wants to drive
    - If you are not driving, then have pen and paper. Take notes of small things to do after the pair splits. Focus on the big things.
    - Put both names in the commit message so you can track who worked on that task.
    - Remote pairing is possible. There are good tools like TeamViewer and Screenhero over there.

    I tried to keep it short… don’t want to write another post here ;)

  • 4. Martin Andrew Habich  |  May 23rd, 2013 at 9:00 am

    Awesome insight! There were times when I was taking notes on my laptop when I wasn’t driving, but that was definitely distracting. I will have to try your analog solution :)

    Jorge, about how often do you take breaks when you’re pairing? I think that most of the time we were probably moving about every hour or so, but there were definitely stretches where we’d go 2-3 hours solid.

    I really didn’t mind pairing and driving all day…physical motion was the biggest issue. Having a better space for it would be helpful, especially with things like having multiple keyboards and a more open desk structure that provides space for both people to move around (we tried to shoehorn it into our existing space, which mostly worked).

    I forgot to mention that we did put both of our names in commits and comments, with a convention that the driver’s name would go first (although I’m not sure that that was ever relevant).

    Have you been able to do remote pairing? It seems like something I’d love to try, but I’m curious how the latency and technological overhead would affect the experience.

  • 5. Jorge Lee  |  May 23rd, 2013 at 12:37 pm

    About the breaks, it depends on the person who are you pairing with. I think every 45 minutes is a good start. That’s why breaking down your tasks into smallers steps helps, you can control the interval.

    One of the great things about pairing is how the communication becomes open. The environment can become quite noisy but overtime you will learn to filter the background noise. This is useful to know what other pairs are doing and even inject yourself into the discussion if you notice some bad decision being taken.

    Yes, I did remote pairing every day for a month and that was not an issue. We have all screen sharing tools, fast internet, skype and google hangout in our hands nowadays.

  • 6. Martin Andrew Habich  |  May 23rd, 2013 at 12:56 pm

    Your comment about the communication is definitely true, even if your whole team is not pairing. I really enjoyed that aspect of it.

    Our team is going to talk soon about how to manage our space (we have a weird setup with multiple buildings and multiple rooms). Part of that will be to discuss designating various environments for the pairing and possibly some “quiet space”. It’s an interesting balance inside a project where pairing is allowable, but not standard practice.

Leave a Comment

Required

Required, hidden


2 + six =

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

© 2010-2014 Summa All Rights Reserved