Tools for Remote Collaboration

For those of you who don’t know, Janson works in Seattle while Aaron and I work in Holland MI. Even though he’s in Seattle, we’re still able to work as if he were in the office. We’ve had pretty good success with a few tools.

Skype and a good microphone

Multiple times a day we call Janson on Skype via our badass Snowball. This microphone rocks, and it’s fairly inexpensive (around $100). It works so well that Janson is able to listen to the music we have playing in the office.

Janson also picked up a Snowflake which has worked great.

I always thought video was key to remote collaborating, but I’ve totally changed my mind. Audio is the first step. Often Janson and I will be working for over an hour via Skype and it feels like the other person is right next to you.

Writeboard

Writeboards are a 37Signals product that are like a versioned document. We use these frequently for asynchronous collaboration.

There are other alternatives to Writeboards, but we’ve found that their low barrier of entry and textile support has helped a lot.

Campfire

Another form of text communication we use regularly are Campfire chat rooms, another 37Signals product. These have been really helpful from pasting code snipbits, uploading shared files and privacy/guest access.

All of us at Elevator Up are very familiar with IRC, and we may switch back to it someday, but Campfire gives us all the chat room features we need without hassle.

EtherPad

Last Monday Janson came across EtherPad and oh boy it’s a gem.

When collaborating on a document we’ve been using a combination of Writeboards/Campfire chats. They do the job, but there’s a ton of “Okay, I saved. Reload.” or “Hrm, I’d rephrase it this way. Lemme copy/paste” which gets rather annoying.

EtherPad on the other hand allows multiple people to be editing text at the same time. As far as I know, it’s very similar to SubEthaEdit but through the browser instead of with a client. It’s helped us out tremendously especially when writing user stories.

EtherPad is in a closed beta, but they are pretty quick to grant beta access. We’ve only been using it for a week, and already consider it a part of our remote toolset.

VPN/SSH/Screen/Vim

Both Janson and I code in Textmate, but we both came from Vim. We’ve toyed with using a VPN to SSH into the other’s machine. Connect to a shared Screen session and code in Vim for Paired Programming. As of yet, we’ve only done it a couple of times, and most of our issues are related to going back into the console for development.

We were both amazed at the responsiveness with a shared session, though thinking back on it, there’s very little traffic compared to other remote solutions. This is one of our rougher tools, but I wouldn’t be surprised if we make this a permanent addition.

Where’s VNC?

Surprisingly we don’t use VNC that often. Sometimes we use it when we need to present to a client who is also remote, but that’s fairly rare. We’ve also found using screen capturing software like SnapX Pro to do a better job when presenting remotely.

Comments 6

  1. I really like the vim/screen/ssh idea!

  2. Anonymous wrote: 21 Dec 2008 at 10:50 pm

    Screen sharing and 2 monitors works better.

    Each share your screen with the other. If you have monitor 1 and 2 on your machine and the other person has monitor 3 and 4 then you would set your monitor 2 to their monitor 3 and their monitor 4 to your monitor 1.

    You can both see what’s going on what the other person is doing, collaborate with out slowing things down.

    OS X has a utility called ScreenSharing built in. We used vim + screen + ssh for about 1 year but have since switched to screen sharing as it’s more natural. So far 2 years and counting. Skype is also a must.

  3. Re: Screen sharing

    Yea, we’ve played with a few different VNC clients. Leopard’s ScreenSharing, TinyVNC, and Chicken of the VNC.

    Our problem was the latency, and using the other tools seemed to “fit” better for what we were trying to accomplish.

    I’m not sure how our pairing differs from yours, but VNC is a bit overkill for our needs.

    • Edit the same code
    • Edit the same text (sometimes different than coding)
    • Share a whiteboard (we’re still working on this one)
    • See the same browser (we can do this through VPN)
    • Audio comm

    We found sharing a desktop didn’t help us much, and in fact due to the latency actually hurt us.

  4. Check out Chad’s “Best Remote Pairing Settings 2008″ — http://pivotallabs.com/users/chad/blog/articles/535-best-remote-pairing-settings-2008

  5. Good post. I wrote a similar one which Joe linked in the previous comment.

    One question – how much do you actually remote pair on web app development?

    Seems like you primarily use Screen/VIM, which is good for console-only stuff; but I find it lacking for real full-time remote pairing on web app development.

    We like to use IDEs, either TextMate or IntelliJ Idea. Most of my co-workers don’t want to use Vim, and I can’t blame them, TextMate/Idea have a lot of benefits over VIM (come on with the flames, but that’s what we believe!).

    Aside from the IDE, there is the issue of testing/debugging webapps and javascript. There are many things you just need to have a shared GUI to pair on: CSS layout/design, javascript testing (jsunit, screwunit, etc), integration testing (selenium, webrat, etc). I don’t see how you could get by with remote pairing on this without a shared GUI.

    As for your problems with GUI sharing performance, check out my notes in my blog post and the comments. Aside from a couple of minor but annoying bugs, Leopard screen sharing is really nice IF you have a really good, fat, low-latency pipe.

    Thanks for the post! – Chad

  6. Hey Chad,

    We really haven’t done a lot of remote pairing, but that’s something Janson and I need to make more time to experiment with this year.

    Regarding the GUI vs Console, I’ve jumped around different IDE’s such as Netbeans, Eclipse, and IntelliJ back when I developed a lot of Java. When I first started working with Ruby, I even started in Eclipse, but quickly migrated to TextMate (which is our current editor of choice). In my opinion, while I admit IDE’s have some nice-to-have features, the features they provide haven’t been a deal breaker when developing in Ruby. In fact most of the time they get in my way. My typical solo development involves TextMate with 2-3 terminal tabs open.

    To be honest, we haven’t had to figure out remote pairing yet. So all my opinions are based on conjecture. If I were to theorize though, I would think we could overcome most of the hurdles doing remote console development.

    First multiple tabs help tremendously, and can be easily done by starting/connecting to multiple screen sessions. Regarding CSS layout/design and Javascript testing, if we’re on a VPN, that means we hit the same server (in our case it’s generally a mongrel). For integration tests, we currently use Cucumber/Webrat so we granted the console freedom, but I could see how using Selenium may present a problem. Lastly, while this seems silly, Apple’s quick screenshot-to-desktop (Command-Shift-4) is really handy when trying to give someone context without VNC/Shared GUI sent through IM/Campfire.

    Then again, once we are tasked with figuring out remote pairing and we compare different solutions I may change my mind and argue for GUI+IDE. I can always be persuaded by sound logic.