Great question! The advice I’ve heard in at least two cases is to create a rate structure with pairing built in. That is, your client doesn’t get a “bonus” by having two programmer work separately, nor a “penalty” pairing: they are paying for output, at your company’s rate, however they get it.
I’m not really the expert in this area since I don’t handle rates and billing. I’m quoting mostly from http://rietta.com/ who gave a presentation at the Atlanta Ruby User Group — the entire video there is enlightening, but skip ahead to 31:00 to hear about convincing clients, billing, etc.
Reach out to them, they might have much more advice than me. Hope that helped!
People always ask me what I use for screen sharing. My answer: Screen Sharing. As in, “Screen Sharing.app,” which is built in to your mac. And guess what:
I’ll take it a step further:
Screen Sharing.app is the best screen sharing application around. You should use it if you can.
"But wait," you say, "I don’t have it on my Mac. I’ve looked in my Applications folder and it doesn’t show up in Spotlight search."
You have it! And you’re right: not only is it not where you expect it to be, but it doesn’t show up in Spotlight.
It’s here: /System/Library/Core Services/Screen Sharing.app
CMD+TABchanges the app on host machine
There are two ways:
Now that I’ve convinced you to use Screen Sharing.app to remote pair, you need to allow screen sharing connections to your Mac in order to host:
vnc://x.x.x.xaddress is the IP address on your local network people can use to connect to your machine. VPN users can likely use this address.
Remote Pair Programming turned 1 today!
There a few networks and services that help people find pairs:
From Kobra.IO’s website:
Kobra is an online code editor that allows you to collaborate with your team quickly and efficiently. After you connect to your development environment, you can see changes in your files as your team members type them. Kobra also has built in video, voice and text chat so you’re never more than a click away from your team.
Currently they are in an open beta: check them out!
Check out this excellent presentation on remote pair programming from Frank Rietta and Brandon Dees, who run Rails web development consultancy rietta.com. They presented at the October 2013 meeting of the Atlanta Ruby Users’ Group.
Slides available here: https://speakerdeck.com/rietta/why-and-how-we-remote-pair-program
Here were some of my take-aways:
One more thing: once they started fielding questions the conversation turned to pairing in general: are there times when they don’t pair? How do they convince their clients pay for pair programming? It seems like someone should do a talk that’s nothing but fielding pair programming questions…
From the book’s page on Prag Prog:
You’ve heard about pair programming’s benefits: fewer bugs, improved skills, and faster delivery. But what happens when you want to pair with someone in another city, country, or even hemisphere? With the right tools, you won’t have to relocate to refactor. In this book, you’ll learn techniques used by the most productive remote programmers in the industry to pair with anyone on the globe on any kind of project. You’ll use collaborative editors, screen sharing, secure networking, and virtualization to create a remote pairing environment that feels as if your partner is sitting right next to you.
I am very impressed with the level of detail and research in the book. The majority of the book describes the technical nuts-and-bolts of remote pairing in different scenarios, focusing on remote pairing on open source projects; I think he does an extremely good job.
Author Joe Kutner conducted a lengthy interview with me, and I tried to convey my remote pairing experiences as accurately as possible. I also had the privilege of reviewing an advanced copy of the book. I’m flattered to be featured in the excerpt along with Jay Haynes of Big Nerd Ranch.
I’m most encouraged by the book’s promotion of pair programming in general. Thank you everyone who has ever paired with me, both remotely and in person. I tried to distill the best of our experiences and patterns in my small contribution to Kutner’s book.
Required disclaimer: all opinions expressed in the Kutner’s book are my own and do not represent those of Pivotal Labs, Go Pivotal, EMC, etc. etc.
When you launch tmate — a fork of tmux — a secure connection is made to a tmate.io server (the site has details on how super-secure and anti man-in-the-middle this is), a tmux session started, and an ssh URL is displayed. Have your pair ssh to that address and boom: they’re pairing on your machine. Pretty slick. You can even set up your own tmate servers.
Hello @thesarahshepherd! Thank you for asking your question. The short answer is no, I have not used any Microsoft screen or code sharing solutions in a very long time. But, I acknowledge that this is a gap in my expertise and I’m excited to see that VS Anywhere is making solutions that support RPP.
I have watched a couple of your videos, including Remote pair programming with VS Anywhere and am encouraged by the what appears to be a pretty slick tool. I do have a suggestion: allow both parties to edit code without an explicit hand-off — that is, allow full editing ability for both parties at all times. The video describes and demonstrates a very narrow definition of RPP and pair programming in general: the navigator and the driver, with a very explicit (and software-enforced) switching of roles. In reality, pair programming is a much more fluid collaboration, with both parties diving into the code as needed; remote pair programming should be the same. Any hinderance to the back-and-forth flow of coding should be eliminated. Supporting a presentation-only mode does make sense, but less so for actual RPP.
I’m sure you’ve heard the phrase “It takes two to tango”. The tango is a fluid dance of two skilled people, moving together. The tango is not one person dancing, while their partner watches them dance on television, shouting suggestions.
@thesarahshepherd delivers! I turns out that VS Anywhere works as I hoped, allowing two collaborators to seamlessly alternate who is coding. This is demonstrated here: http://www.youtube.com/watch?v=f7epkbVuEYc. I would recommend that this kind of interaction be the focus of your remote pair programming video.