Tuesday, February 24, 2009

Remote Pairing Day 2

I'm in a new position, and it is part of the deal that I work from home. Anybody's home. I'm learning the art of remote pairing, and will give some pointers here as I explore the space.

Tech

Today I want to mention some technology we're using. So far I've tried a few free remote solutions, and found them to be awfully laggy and troublesome. I'm so open to an open-source solution or two.

So far I've done the A/V portion using google chat extensions and skype. Of the two, I had google drop out less and they both keep up to date pretty well. I was happy that there wasn't a lot of lag and pixelization with either. The video is grainy, but it does help to have facial expressions in a discussion.

The screen sharing we've liked best have come through commercial services LogMeOn and TeamView. We've been using the free trial editions, and both seem to work very well. By "working well" I mean that
  • Connection isn't dropped too often
  • There is no troublesome degree of lag
  • We can work trade driver/navigator without "mother may I" coordination
  • It looks roughly the same on both sides
I would most love to add "works for Linux or Windows" to that, but that's not strictly required. I'm doing windows-only this week, and we can run putty or msys for text-mode linux session sharing. I wonder if this is the first really legitimate use of Windows I've had in a few years. If that's where all the screen-sharing, pair-programming magic is, then windows has a place in my toolbox after all.

Experience


I also attended my first architecture meeting via webcam & mic. It could have been better, and I eventually fell out of the meeting. But it was helpful for a while.

With the lag resolved, it wasn't nearly so bad. I was able to even listen on conversations with other developers when we hit snags. We didn't produce a ton of code, but we were able to produce a number of tests and refactor them pretty well. The code became clear enough that we saw some flaws in our approach and corrected them in flight, and stayed within a very few minutes of the last green test run at all times.

Concentrating the fact that's I'm peeking through a keyhole, I actually skipped the 'red' in a red-green-refactor cycle. When I realized it, I commented out some code (only one line) and got the red bar I needed. Then I uncommented it and got a proper green bar.

I also have not been switching partners so much. I have a partner (also named Tim, though I'm Ottinger and he's Gifford) and we've been working together Friday, yesterday, and today. It's going well, though I know that as I get more of the system loaded into my head we should be starting to trade partners. I got to work on that "load program into head" system.

I'm relearning RhinoMocks, C#, Visual Studio, and Resharper after a long hiatus. I'm working with good people, and we're making some progress and might have something worth showing someone tomorrow or the next day. And I'm doing it from a great distance. It really hasn't been frustrating as I expected. The technology is much better than last time I tried, and the task is discrete enough.

Lessons Learned

Punctuality: I got mixed up between timezones and my partner had to wait for me or go on without me. This won't be a problem in Illinois, but working from Indiana meant that I have to know what time zone each watch and clock and computer is on. I need to be ready when the parner is ready, especially when we've pre-arranged a time.

Second computer: though a second computer is normally a distraction, it might be good for remote pairing. if the second computer provides the A/V and stands by with documentation on language/frameworks/etc then it might not be a pairing smellat all. It might even be a good thing.

Equipment: I want more monitors. I love my on-ear active noise reduction headphones. And a laptop I can take from room to room if one space must necessarily be loud for a little while. And wifi. Mmmmm... wifi.

Technique: I use the online stopwatch to count down 48-minute pairing sessions, after which we try to take 12-minute breaks. It saves eyestrain and gives your head a chance to clear between sessions. We're actually struggling to make the breaks last that long, but I wanted to give this system a fair shake. Oh, and we pretty much live by the ABCs if you ignore the C bit.

So far, so good!

1 comment:

  1. The tech I've used for remote pairing is usually skype for audio/visual (seeing your pair adds so much over just audio). For editing we use a shared unix screen session (both log info a common unix server and share a terminal/edit session). Very little lag, but also no graphical IDEs. The only remaining issue is for web developement, we use our own local browsers and sometimes don't see the same results.

    ReplyDelete