For almost a year, I pair programmed on a daily basis as part of a team working for GeoLearning, a small software company that is no more. My enjoyment was tempered by the fact that I was pairing remotely, online with a headset and sometimes a camera, using Skype and WebEx. The contrast to live pairing was marked.
Remote Pairing Cons
-
Lag. Whoever was not hosting the session suffered enough lag to make the experience a bit painful. We didn’t switch enough, probably because of the cost of switching overhead (not only the desktop switching itself, but also getting the source across, which really isn’t all that big a deal with git).
-
Noise. Some people breathe rather heavily, others swallow loudly, and some like to chomp on snacks too much. I did mention it from time to time, but it always felt awkward. And either I was a very good pair, not making these sorts of noises–I doubt it–or others similarly didn’t want to speak up.
Pairing or not, as a remote developer I didn’t feel like I was a real part of the larger, “live” team. I felt that my influence as a remote person was insufficient.
The remote pairing also carried the same issues that “live” pairing can create, most of which are minor. For example, the team had very few standards, which led to some wasteful debates during many of the pairing sessions, still not that big a deal. But couple a lack of standards with stubborn people, and you have a useless pairing session.
I can get along with just about everybody; not the case this time out. I paired with one developer whose concept of TDD was almost completely opposite mine. We produced virtually no useful product during our two or three pairing sessions (we then ended up on different teams, thankfully). In attempts to stop the arguments, I would often say, “Let’s just go with your preferred way of doing things for now.” No such luck. Some folks are simply contrarians.
Remote Pairing Pros
-
It allowed me to stay at home, very welcome after many years of travel, which had created a significant negative impact on my family life.
-
Learning a new system without the ability to lean on someone for several hours a day is tremendously wasteful and frustrating. Remote and isolated, it’s even worse. Pairing rapidly brought me up to speed to the point where I was able to contribute.
-
I could work with the remote pair and not be uncomfortable about things like sitting too close, bad breath, or my laziness on some days when I didn’t feel like showering.
-
The slow cycle times (waiting on compiles, test runs, etc.) were almost bearable due to the fact that you had someone to talk to for the minute or two or more.
Being remote sucks in so many ways–primarily the isolation from the rest of the team–that I wouldn’t have even considered the position had it not been for the ability to pair. I never felt like I was a real part of the larger, “live” team, and I felt that as a remote person I was unable to influence the team much.
So despite the negative aspects of my remote pairing experience, it was the best that I could expect for this opportunity. Ultimately, having this opportunity remotely was better than not having it. And the pairing brought me a small but significant step toward feeling like I was a real part of something.
Pairing No More
I’m currently working a three-month contract for a local firm. It’s a very stable company, there’s no travel on the near horizon, and my commute is about seven minutes door-to-door (it’s three miles away, with only one stoplight inbetween). Those three elements are great, but just about every other element–ranging from pay to preferred way of working to technology–is a concession.
There’s no pairing. My first “real” week (i.e. past most of the HR and setup BS) was spent sitting in an office, digging through a (test-less) codebase, occasionally IMing my teammate a couple offices over to ask questions. It’s a typical no-process environment.
Here’s how I feel about no longer pairing:
-
Bored. Cycle times are again high. I miss having someone to discuss things with during the waits. Checking email, tweets, RSS feeds, and Amazon book ranks helps only a little.
-
Lonely. Stuck in my office with no one to talk to and bounce ideas off, I don’t really feel like I’m part of a team, just one of a number of individuals who happen to work on the same code base and project.
-
Conflicted. I second-guess myself continually. “Is this the company way? Is this the [unfamiliar-to-me technology] way? Does it violate standards? Is it the best design? Did I just do something really stupid? Am I going to get chewed out or look bad for checking this code in?” Unfortunately, second-guessing produces far weaker answers than simply asking someone who already knows and can quickly tell me the answers.
-
Released. One downside of pairing most of the time is it tends to suppress learning by exploration. While I don’t want to work that way all of the time, I’ve found I often learn better when I probe about and try things. With a pair, I usually feel the pressure (even if I’m really the one creating that pressure myself) to move on. And many people who already know the answer tend to simply prefer to tell you it, or more typically grab control and do it themselves rather than wait while you muck around.
While this may sound damning, it’s easily rectified in a pairing environment: Set a time limit to pairing. I’ve found that a six-hour window is plenty, but it’s up to you and your team to figure out how much works well for you.
Pairing is not for everyone or every team. The bullets above suggest that there are serious challenges both with pairing and with not pairing. But most of the time, I’ve found pairing to be far more enjoyable and productive than not.
Comments
It’s interesting how productivity is directly related pairing especially in a new environment. I have experienced the frustrations of being alone in a foreign code base that are caused by uncertainty.
I started a new job a few months back and I certainly feel benefited by pair programming. Having never worked professionally with the environment, language, or web framework I admit I was very intimidated by the unfamiliar set of tools.
Two months in and the obstacles have been cleared. I can comfortably make changes in the code base and write well suited unit tests to cover fundamental functionality. I have learned much from my peers and continue to teach and learn as we work together.
I understand your frustrations with remote pairing (especially the constant issues with networking). In my experience working with remote employees I have really enjoyed it, but I have never been on the remote side of things.
“And either I was a very good pair, not making these sorts of
noises–I doubt it–or others similarly didn’t want to speak up.”
– You were a VERY good pair (besides maybe the chewing sounds of
granola 😉 but that wasn’t bothersome)
Thanks JR! I’m wondering–maybe doing remote pairing from the central office is something that gives you a break from dealing with all the people in the office? I’m betting for some people that’s a plus.
Hope your new job is working well for you!
Interesting article, I’ve not done much, remote pair programming, but we’ve been doing quite a lot of pair programming in the office. What do you think that could make it work better?
When you say there aren’t many standards or processes, do you mean in relation to pairing specifically or development in general? What standards or etiquette do you think are relevant? We have a standardised coding style but it doesn’t go into how to write our unit tests. Was the team working using Scrum etc or was it more adhoc?
Looks like you experienced what I characterised as the “argumentative a**hole”.
It’s interesting that you found this while doing TDD, When we had a
meeting about pair programming we almost all agreed that TDD was an
important part of feeling productive with pairing.
here’s the link if you’re interested:
http://www.d80.co.uk/post/2011/03/05/Pairing-Doesnt-Work-Without-TDD.aspx
Thanks for the link Dan!
With respect to standards, I mean more in general–such as the fact that we’re all doing TDD (as defined) or not. I definitely think some level of coding standards, warning standards, build standards, and testing standards are important, particularly in a remote environment. They don’t have to be exhaustive or presented in excruciating detail (and in fact too much here can be a problem, too), but they do need to be something the team can live with and also something the team revisits on a regular basis.
This team wasn’t really doing much in the way of larger process; it was very ad hoc. They had embarked on XP-like process a couple years before I arrive, and the only things left that I saw were TDD and pairing. As the software and company grew, they split into multiple teams, and apparently lost control of a lot of things.
My simple take regarding standards is that a team who can’t agree on and adhere to some small level of standards isn’t much of a team.
I think a lot of this happens because we don’t socialize the code enough. Pairing is a good start, but only if you switch often. Outside of pairing, we need to find ways to discuss the system as a whole team on a regular basis.
As far as making remote pairing work: I wish for a way to do IDE-level sharing at a character level, not GUI level. One naive idea: send only a subset of events sent to the IDE remotely (e.g. key events but not mouse events, command events, …).
Pingback: Langr Software Solutions » Where Are the *Real* Agile Tools?
