A Guide to Remote Pair Programming Tools

Update: Article about the newly released Tuple pair programming application.

With Slack’s notification of Screenhero being end-of-life’d we at Zeal are looking for new solutions to a problem that had been already solved. While Screenhero wasn’t perfect (as really nothing can be) it did its job very well for our environment.

Screenhero is a good place to start our review as it gives a baseline of why it solved our business problem. I will use it as a way of defining our environment. From there, I will extract some features that are important to us. Then, I’ll define types of tools and their ability to meet our features. Finally, I will quickly review what contenders are out there.

Screenhero

When Screenhero came along there was nothing filling the seamless pairing tool space. There were other screen sharing solutions, but no other tool gave the kind of interactive session between two or more people that Screenhero offered.

The reason this is important to us is because we are a consultancy that prides itself in XP methodologies, including pair programming. Our daily work includes pairing with other members of our company and pairing with our client developers. Since many of Zeal’s developers are remote and not sitting with our clients (or each other), we have a need for tools that will solve this geographic problem. Here is a quick list of environmental items that feed into our pairing tool’s features.

• XP methodologies
• Multiple client code bases
• Pairing with client, open source, and internal developers
• Mostly Mac, but some Windows clients

Since Screenhero had no competition that could sway us from our nice comfortable tool, we got used to a few features that we don’t want to do without now. These include control of a person’s machine with multiple cursors, minimal lag, and shared context (ability to open all programs on the screen, not just one window). With Screenhero we could copy and paste between systems, switch applications with Command+Tab, and switch between system being shared. Inviting new users was easy. The peer-to-peer nature made code security a non-issue. And the cost — at free — was amazing.

There were hiccups and shortcomings occasionally. We needed to restart Screenhero from time-to-time, had to agree on editors and setup, and there was no video to see your fellow pair.

These paled in comparison to the abilities it gave us to perform our jobs with little interference. It became a core tool of our group.

Pairing Tool Features

• Dual control (multiple pointers/prompts)
• Minimal lag
• Cross-org & guest support
• Security of code/communication
• Support for more than two people at a time
• Full keyboard support (e.g. application switching)
• Copy/paste between systems
• Context switching awareness (e.g. when we bounce from editor to browser)
• Audio/video support
• Editor/IDE agnostic
• Cost

Types of Tools

There are several contenders that break down into different groups. Each tool falls into one of these categories. Of these types, only the ones that say “Share” in their names take remote collaboration into account. To me, “share” is a two-way interactive session.

• Screen Show (e.g. Google Hangouts)
• Screen Control (e.g. Mac Screen Share/VNC)
• Screen Share (e.g. Screenhero)
• Application Share (e.g. Atom Teletype)

Screen Show

These are tools that only allow someone to view the others desktop or application. They’re great for presentations, but not for remote pairing. In this case, the viewer can only use words to talk through their work. Because of our team’s highly collaborative work style, I didn’t even look at these as a possibility. Google Hangouts, Goto Meeting, and AppearIn are examples of these tools.

Screen Control

A tool like Mac Screen Control/VNC is a prime example of screen control. There is one mouse and no A/V. It allows one user to access and control the desktop of another machine. This is great in the system administration world where remote machines need maintenance or a user needs support. There is either no one on the other end or they sit their passively while someone fixes something for them.

Because of this, they make for horrible remote pairing tools. I extend this set of tools to anything that does not at least allow two cursors that act independently of one another. If you don’t have two cursors, one of the participants has to sit back and not touch the keyboard and mouse, and thus they aren’t really participating in the pairing process. They can talk through switching whose controlling, but it seriously interrupts workflow.

There are several “Screen Share” application I would then include under screen control because of the passive nature of the pairing. Below are the tools that I tried out and any pros/cons about them.

Mac Screen Share/VNC

• Pros: Good performance depending on network, cost
• Cons: Requires local/VPN access or port forwarding, not cross-org friendly, no A/V

Teamviewer

• Pros: Typing speed is responsive
• Cons: Mouse scroll was slow

Join.me

• Pros: Good A/V
• Cons: Text editing and mouse scroll were laggy

Zoom

• Pros: Outstanding A/V
• Cons: Laggy, but best out of the bunch

Screen Share

These tools allow for a two-way interactive session where one person is sharing their desktop. But in this case the person they are sharing with can control their own mouse cursor. This is really important for allowing both individuals point out things out without feeling like they are stepping on each others toes.

There are some drawbacks to this solution, due to the fact that two contributors are sharing the same screen. Both people can’t be typing at the same time and are locked into whatever tools the screen host prefers.

This is what Screenhero was, and what Slack’s replacement is. I will dive into the options in this category below.

Application Share

This category seems to be growing quickly. The tool that created this group for me was ngrok. While not directly a given application, it allowed me an my early pairs, who were all VIM and command line users, to solve our remoteness issues.

Now other applications are deciding to solve remote pair programming by allowing sharing of code within the confines of a given application. Some are very interesting in their solutions and this category is showing the most promise.

Most of these tools require multiple applications to solve the same issue as one tool did before. Usually A/V is not handled, context switching can be an issue, and access to things other than just the editor.

The hiccup of Slack and Screenhero might be giving this category some legs to see what it can do. I will review these tools below in the contenders.

Contenders

Since the only tools that really matter to me are the ones where sharing is the cornerstone of the workflow this list is rather short.

• Slack (Screen Share)
• Use Together (Screen Share)
• Floobits (Application Share)
• Atom Teletype (Application Share)
• Visual Studio Live Share (Application Share)
• AWS Cloud9 (Application Share)

Slack

Slack’s decision to shutdown Screenhero and move its functionality into their application is the right decision. I completely understand and want to see it succeed. I also see them working very hard on it and constantly improving the tool in its very short life.

That said… their implementation has a lot to be desired. They only released the interactive set of tools recently. And at the same time, they announced Screenhero had little over a month of life left.

The biggest issues I’ve experienced are lag and flakiness. Slack has the ability to have video so the person who is sharing their screen can see the other participant, which is a good addition, but without two way video it seems half done. Using video also makes the lag worse. I would imagine there are some memory leaks, because over time some features, like the ability for a participant to interact with the shared screen, just stop working.

Slack’s decision to shutdown Screenhero while still working out the kinks and bugs is very disheartening. I really want to see them succeed and I think they will fix these issues, but until that happens, we will continue to search for tools that will work. And it may happen at that point we find something better.

Use Together

Soon after the Screenhero end-of-life announcement, Use Together released an alpha version of their screen sharing application which we got to test. While it is alpha and buggy it shows a lot of promise.

The host is the only one that needs an account. They download and run the native app. They need a login, but then they can invite anyone to join via an HTTP url. This then allows a remote user to connect to their machine via the browser.

I was expecting horrible performance, but it was quite good. While not as smooth as Screenhero, it was acceptable. You still needed a secondary application for A/V, but that is acceptable as well. I will be following what they are able to accomplish over their release cycle.

Floobits

Floobits was the first editor based sharing tool I tested. I was highly impressed with its support for different editors like Atom, Sublime, IntelliJ, etc. So this means everyone can have their own environment. Finally VIM and Emacs users can unite!

It has built-in A/V via WebRTC (at least in Atom) for easy communication without the need of an additional application. It also enables access to the shell via the editor’s built-in terminal.

The biggest downfall for our environment is uploading of the codebase to a central Floobits server. While you can keep it private and secure, there is a certain air of uncertainty with this solution. I know we upload our code to Github, Amazon, CI services, etc… but for some reason it seems riskier here.

I think this is an amazing open-source/mentoring platform and it has possibilities for more. But I will let it bake in a bit before trying it for a client solution.

Atom Teletype

Sometime around the Screenhero announcement Atom Teletype was pushed out (there seems to be a common thread of new tool announcements with the Screenhero end-of-life notification). This is an Atom-editor-only tool. It is taking its first steps and they are small.

You get a share button in the bottom of the screen where you login and then are able to share your current project via a peer-to-peer connection. This solves the issue of Floobits uploading code.

The remote person connects and sees whatever tabs the primary developer has open… and that is about it. No file tree for navigating, no terminal, no A/V. However each dev has their environment in atom setup the way they like it. So one could be in VIM mode, and the other not.

The file navigation is a big detractor, but not enough to close this as an option. For A/V we have been using Zoom, which is amazing. For other services we have been using either ngrok or tmate.

While this isn’t quite smooth yet, and requires us to adopt a slightly different communication style to ensure our partners are on the same page in terms of application context, it’s worth exploring further. It is still early and since its only market is pair programming we expect it to get better with time.

Visual Studio [Code] Live Share

Another recent announcement came from Microsoft. Their Visual Studio and Visual Studio Code tools are getting something called Live Share. This looks very similar to the Atom Teletype, but with more features. It looks like it integrates with the whole application, so you get file browser and debugging.

This is currently not yet out so I do not have any first-hand experience. I haven’t had a Microsoft product on any of my systems in a very long time, but this might be where I jump back into that ring. I look forward to seeing what they put out.

AWS Cloud9

The final announcement that came out just days before Screenhero shut down was from Amazon. AWS Cloud9 was released on the Amazon platform of tools. Many of you may remember Cloud9 was an in-browser editor that Amazon picked up. Well, they have now turned it into a new offering.

It is an interesting possible solution, as many of our clients already have their code on AWS. So that is an easy sell for some. The initial drawback for us is that not all of our clients have code there. While you can use other third party services, it seems a bit more complicated to setup.

My full-disclosure is I have not tested this as an option, mainly because of the AWS account creation requirement. If that is something that doesn’t scare you away I would love to hear some feedback on it from a pairing tool perspective.

Conclusion

Right now we are floundering around trying to solve this issue for our team. Our best option is two-fold. If it is just a quick session we are mostly using Slack’s functionality for simplicity. If it is anything longer, we have been using Atom Teletype, along with Zoom and ngrok/tmate to get all the features we need.

None of these solutions are our go-to like Screenhero was. It is only a matter of time before a solution is solidified enough for our long term use.