Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Do the Google Hangout Hop

Bit.ly + static hangout links = quick feedback loops.

Quick feedback loops are core to the Pivotal process. Effective communication enables successful agile projects. Pairing, stand-ups, and retros are all designed to facilitate information exchange. But regular ad-hoc conversations between teammates are important too.  

Read more »

PIVOTAL LABS
Internet IRL: Hard won lessons from Tough Mudder

Tough Mudder technologist, Ori Neidich, discusses hard-won lessons in bringing high-availability portable network operations to physical events in remote locations.

Watch live streaming video from pivotallabs at livestream.com



Read more »

LABS
How We Use tmux for Remote Pair Programming

Update 07/18/2012: We have added tmux-vim autosaving support as a Vim plugin. It's available here: https://github.com/pivotal/tmux-config

Update 07/20/2012: There is a lively discussion on Hacker News about this post in addition to the comments below.

tmux is the cool kid on the block for remote pair programming, as long as you are using a terminal based editor such as Vim or Emacs.

There is no shortage of tutorials and guides regarding how to use tmux, thus my only introduction to tmux will be this: tmux is a terminal multiplexer and supports shared terminal usage.

Our large software project used tmux regularly for remote pair programming and settled on a configuration that has worked well for our team. Read on to learn about tmux's advantages and disadvantages vs. desktop screen sharing, why and how we used it, and how we addressed the many challenges of remote pairing using tmux.

LABS
Integrating Remote Developers: Intuitive, Flexible Video Conferencing

I recently blogged about about integrating remote developers with large development teams. An important but finicky part of bridging the gap between remote developers and the rest of the team is video conferencing.

How hard can this be? It's Skype, right? While most techies know how to use Skype to make video calls, the difficulty is managing headsets, external microphones, external speakers, and switching between all of these frequently throughout the day. Despite what Apple might tell you, it does not "just work", especially Skype, which has a particularly baffling user interface.

Early in our large project's history the following scene played out frequently:

  1. Office developer sits down at a workstation and Skype's a remote developer.
  2. They can't hear each other!
  3. Office developer finds headset is unplugged, plugs it in to Skype laptop.
  4. Still can't hear!
  5. Office dev opens the Mac sound preferences, clicks around a bit.
  6. Still can't hear!
  7. Office dev dives into Skype sound preferences… Ah-ha! Select headset.
  8. Still can't hear!
  9. Remote developer starts messing with his own preferences, settings, cords…
  10. Bingo! Finally, they can hear each other, but suddenly…
  11. Someone in the office needs to talk to both developers.
  12. Office dev starts changing audio settings again, plugging/unplugging stuff…
  13. After several minutes a group conversation can be held.
  14. Group conversation is over. Go to Step 1.

The Need: Intuitive, Flexible Video Conferencing

Actually, it's mostly about the audio: the video usually works fine. We needed a means to easily switch between pairing-mode and group-conversation-mode -- that is, between headphones + mic and external speakers + external mic. Above all else we wanted to avoid constantly changing software preferences. We needed something as easy as pressing a button or plugging/unplugging a single jack.

So far we have found two solutions that work well:

  • Solution 1: External Speakers with Headphone Input: An external microphone, external speakers with a headphone jack, and regular "music" headphones.
  • Solution 2: Seamless USB Audio Input Switching for Skype: An external microphone, external speakers, a USB headset, and a bit of special Mac and Skype configuration.

Read on for more details.

LABS
Integrating Remote Developers into Large Teams

I'm obsessed with remote pair programming and remote collaboration. I've even given tech talks about remote pair programming. Most teams with which I've worked remotely are small -- usually around four to six team members total -- but for the past 10 months I have remote paired on a project of up to 30 developers. While the majority of the team was co-located in our NYC office, five of us were remote. Over that time we have tried many different remote collaboration and pairing setups and feel we've settled on a configuration that supports daily pair rotation with minimum overhead.

LABS
Syncing IntelliJ Android .apk Files Using Dropbox

During a typical day of Android development we compile Android applications (.apk files) dozens of times, deploying to emulators and devices simply by pressing the Run button in IntelliJ. This is great for our in-office developers, but it's more difficult for our remote-pairing developers to install those same .apks on their own emulators and phones. As a remote developer, I wanted seamless, instant access to all .apks we build during development. Using Dropbox and some IntelliJ configuration changes I now have all .apks we build available for me to install on my local emulators and phones just seconds after we build them on our development machines, 2500 miles away.

LABS
Best Remote Pairing Settings 2008

About a year and a half ago, I made two posts on the "Best Remote Pairing Settings".

A Remote Pair

The world has moved on, and so has the state of the art in remote pairing. I work remote 75% of the time, so this is an important topic for me. The setup we have now is working pretty good, so I wanted to describe it for the benefit of other remoties. Also, I'm only going to describe one specific setup - the one that is currently working best for me. So, here it is:

Computer and OS

Macintoshes running OS X 10.5 (Leopard) and maxed out on ram (at least 2 gig+), with a second monitor, ideally a 24".

Pivotal uses 24" iMacs exclusively. This lets you have your remote pair's screen up on the second monitor, while still having the primary iMac screen available for local work (configuration, looking stuff up, temporary soloing, etc). You must be very disciplined and up-front - you should be explicit about when you are paying attention to your pair and when you are not, but that's a whole other topic.

Also, at my home office, I have an iMac which I use for screen sharing, but I usually run the Skype audio/video on my MacBook. This takes the CPU load off of the iMac, which is important, because Skype is a CPU hog (more on that later).

Screen Sharing Software

Apple Screen Sharing which comes with Leopard.

Apple has done a nice job making the screen sharing app perform well, and the most important feature for any remote pairing screen sharing tool is performance. In my opinion, it performs better than any other VNC client on any platform, assuming you have a good connection (possibly excluding some windows native-video-hook solutions like UltraVNC or Remote Desktop, but there's no way I would ever use Windows for development). All VNC clients which use the standard RFB Protocol can only be tweaked so much, and will only give you mediocre performance. However, there are several annoying bugs and gotchas with Apple Screen Sharing:

  • It is hard to find. Look under /System/Library/CoreServices/Screen Sharing.app. It is easiest to use Spotlight/Quicksilver or drag it to your dock. Supposedly you can start it with iChat but this never worked for me, I had to run the app directly.
  • Most of the useful features are disabled by default with no way to access them via menu or toolbar buttons. This is an amazingly annoying decision by Apple, but it is fairly easy to hack the toolbar buttons back into existence. Here is a Macworld tutorial showing two options.

In general, it seems that the best remote-control tools are those with some sort of native/low-level GUI integration: Leopard Screen Sharing, NoMachine NX, UltraVNC, Windows Remote Desktop, etc. Higher-level platform agnostic tools (like standard VNC/RFB protocol) just don't perform as well - no matter how much you tweak the available color/depth/etc settings.

Audio/Video Hardware

Plantronics GamePro USB Headset

This is a great headset, and you need a really good headset if you are going to wear it all day, every day. Cloth earpieces, mic cover, very long cord, and I believe it also has some echo cancellation built in (there's a huge box inline in the cord that does something). Unfortunately, I don't see the exact model on the Plantronics website anymore. It may be replaced by the "GameCom" model, but I haven't tried this.

Built-in iMac Microphone/Speaker

The built-in microphone and speaker on iMacs is really good. If you want to talk to a group of people remotely (for example, project standup), this is the way to do it. However, if the ambient noise gets too much, you can switch back to the headset.

You can even combine the two. For example, if you want to hear the surrounding conversations, but your pair is having trouble hearing you over the noise, then can wear the headset, but still keep the input set to the built-in iMac mic.

Sometimes you will need to adjust the input/output levels to reduce echo, and the remote pair should handle this themselves - they know what it sounds like.

Built-in iMac camera

Just like the built-in iMac mic and speaker, the iSight is a great camera. A detached iSight is just as good, if you want to be able to move it around or aim it without moving the computer.

Audio/Video Software

Skype

Skype is the best I've found. It does have drawbacks: it crashes rather frequently, it sucks a lot of CPU, it can do bad things to your network if you become a supernode, and it doesn't support video in conferences.

However, it has great echo cancellation, it is free, and easy to use. The echo cancellation is really the most important thing - all other audio conferencing tools I've tried seem to have much more issues with echoes - even when you are using echo-cancelling hardware devices or speakerphones.

Some people seem to like iChat, but I have not had good luck with it. It takes longer than Skype to connect, the echo cancellation is not as good (sometimes it is, sometimes not), and most annoyingly, it doesn't always close. I often end up having to force quit it - which is even more annoying when it is stuck on a freeze-frame of me making a stupid face or scratching my nose. Skype never does this - video always goes away when you shut your video or kill the call.

iChat has video conferencing, though, which is a benefit. You can sort of work around this by putting up the video preview in iChat, and having multiple remote people connect to view it via screen sharing, if you only want to see video for one of the participants (e.g. a couple of remote people calling in to a company meeting).

Network, Network, Network

This is the last but most important component to usable remote pairing. A fast, low-latency network connection is critical. I don't have any numbers, but I believe that low latency is at least as important as high bandwidth. I also (without proof) believe that ping is not necessarily a good indicator of latency - I bet it is possible to have a good ping (ICMP) but still have issues with TCP/UDP latency. Who knows what's going on in the tubes between you and your pair? Any data, tools, or insight on this would be very welcome.

As empirical evidence, for the first year or two at Pivotal I had DSL, which was pretty fast with low ping, but had continual problems with performance. Then, I switched to corporate-grade cable with a significantly higher bandwidth limit. My experience improved dramatically and my problems decreased greatly. This was about the same time I switched to Leopard screen sharing, so I think that had something to do with it, but the better connection definitely made a huge difference. Again, sorry I don't have more concrete numbers, but I will guarantee that the better your connection, the better your experience will be.

Also, if you are in a corporate network, this may cause you problems. Even if there is a big pipe to your location, there may be saturation on your local LANs or intranet. Again, no hard data, but this is backed up by experiences of having consistently better performance when connecting to another remote at-home pair with a good connection as opposed to connecting to the Pivotal office which has a much larger pipe.

Remote Pairing Presentation at RailsConf 2008

  • At RailsConf 2008, Michael Buffington and Joe O'Brien did a good presentation on Remote Pairing. This is a very good presentation which covered many important aspects of remote pairing, as well as presenting some innovative ideas. Unfortunately, I don't see a link to the preso, please post one in the comments if you have it.

Summary

This isn't meant to be the be-all, end-all set of recommendations, it's just what is working pretty well for me now. By "pretty well", I mean that I can be an efficient pair, even when I'm driving the remote machine.

However, I've learned to cope with a lot, and adapted my work habits. It has forced me to become much better at communication, and describing what, why, and how I am programming. In general, though, I believe that remote pairing is physically, emotionally, and intellectually taxing. Regardless, I personally deal with it because Pivotal is such an awesome place to work and Pivots are such incredible developers. Most importantly, I come out in person for a week every month, attend retrospectives and brownbags, have some beers, and generally stay "entangled" with the rest of the team in person. If I was 100% remote, I don't think I could handle it long-term.

So, I hope this helps out all the other remoties out there. Please let me know what you think, your experiences, and what works well for you.