Remote Pair Programming
Posted by Doug Tue, 09 Oct 2007 13:47:00 GMT
I mentioned in my post the other day about remote pair programming and someone called me out on it via email. Since I spend probably between 40 – 60% of my work time remote pair programming I thought I’d give some of my experiences.
First, some background. I’ve been moonlighting as a freelance web developer for a lot of years. I work with David Minor at Sus 4. He and I have done remote pair programming on almost all of our projects for the last four years. I also telecommute for my day job into blah blah blah (lawyers made me change this). I travel to the headquarters in VA once a month or so, but work from home the other three or four weeks. Probably half to three-quarters of my programming tasks at blah blah blah (lawyers made me change this) I pair with another developer. There are several different people that I’ve paired with regularly over the almost two years I’ve been there. Finally, I’ve talked a lot about remote pair programming at the Cincinnati Agile Round Table. From their Jim Weirich has picked up on my techniques while doing remote pairing at Edge Case.
What I’m trying to say here is that I have done a lot of remote pair programming over the years and I’ve tried a lot of different techniques. What I’m about to describe here is tried, tested, and proved.
Being on a Mac, I have paid licenses of both TextMate and SubethaEdit. They are both fine editors. I think I prefer TextMat over Subetha simply because I think TM handles projects better. However, I do think Subetha’s networking and multi-user support is really cool. The problem is with Rails projects I always end up with lots and lots of files open. Subetha doesn’t make it easy enough to share the files by default or for the remote guy to join their shared files by default. Plus, with TDD you have to have some way for both partners to see the test output.
While talking about things that don’t work… there’s just not enough bandwidth for VNC. I’ve done all I know to do to optimize it: drop the number of colors, change backgrounds to solid colors, muck with compression algorithms. I just can’t quite squeeze enough bandwidth out so that it feels interactive for both people.
So what does work? Welcome to the past. What I’ve found is that gnu screen running inside a terminal is the most bandwidth efficient, highly interactive, flexible multi-user environment. One person hosts, the other connects via ssh and joins the hosts screen session. For those who’ve never used screen, both users connected see exactly the same thing. Both users keyboards have simultaneous control of the terminal. Combine this with a good voice/video channel with Skype or iChat and it’s nearly as good as actually sitting next to someone.
Inside of screen you can have multiple tabs/windows. What I typically do is designate my first window to run emacs. This is my “IDE”. We do all text editing from inside there. I have another window designated for running tests (although sometimes I run tests from inside emacs). I have another window designated for the mysql prompt. Another is for tailing log files and another for running the server. Screen saves the history (I typically set it to something ridiculously large). Both people can see when you scroll through the buffer history. Both people can see all the data.
I’ve kinda glossed over the use of emacs here. I’ve also done remote pairing with vi (well, vim anyway). The point is that it helps a great deal if you’re using an editor that both people understand. I pair with a guy at work that only begrudgingly uses emacs. It’s not nearly as much fun for him. I’ve also paired with folks who aren’t comfortable with any terminal based editor. That’s no fun either.
Like pair programming when you’re actually together, there are a number of things to consider. Editor environments is one of them. Remote pair programming seems to heighten or exacerbate all the issues with local pair programming. Your communication issues are bigger. You really have to make a point to tell each other what you’re doing. Talk, talk, talk! A definite anti-pattern is one of the people in the pair going off to work on solutions locally on their own computer while the other person can’t see what’s going on. Do all work in the screen session. Make sure that both people can see everything that’s going on. Related to this, it’s hard for one person to “see” when the other is distracted. If one person is checking email while the other is trying to stay on task that’s no good.
The good news is that remote pair programming can work. I find actually pair programming in person to be very fulfilling, fun, and exciting. Remote pair programming isn’t as good as actually being together in the same room. However, it’s a very good substitute when the commute cost are high. If you’re the kind of person that doesn’t really dig pair programming in general, odds are you’ll find remote pair programming to be even less attractive than actual pairing.
I’ll also mention I know one guy (whom I respect a lot) who’s big on pair programming, but just can’t get in the groove of remote pair programming. I suspect his problem is lack of familiarity with the editor, but there may be other philosophical issues as well.
All that said, I don’t find running emacs inside a screen to be some “least common denominator”. In fact, I do all of my development this way—even when I’m not pairing. Lately I’ve been running multiple screen sessions on my box; one for each project I’ve got going. My “state” is always right where I left off. When I switch from independent work to pairing, it’s easy for someone to simply join my screen and we can get started. I’ll stop here and not get too carried away with singing emacs’ praises. That’ll be good info for another post…
Before I close out, it occurs to me that screen can be pretty ugly with zero config. I’ll go ahead an post my hard status config. This dresses things up quite a bit and makes it a lot easier to use. Put these lines in ~/.screenrc:
hardstatus on
hardstatus alwayslastline
hardstatus string "%{rk}%H %{gk}%c %{yk}%M%d %{wk}%?%-Lw%?%{bw}%n*%f%t%?(%u)%?%{wk}%?%+Lw%?"
Have you tried using M-x make-frame-on-display so you don’t get tied to screen? I suppose that would mean you’d have to do all your shell tasks within emacs to still get the benefits, but if you’re already using eshell or ansi-term then it’s no big deal. That’s what I’d try in the same situation anyway.
I’ve started using inf-ruby mode with an ssh-bound ruby process to access production rails consoles; it’s pretty flexible. I’m sure you could do the same with MySQL.
Maybe I’m wrong, but that seems like it’d require me to have X11 running. Mainly for memory and ugliness reasons I avoid X when I can. I really am comfortable with
emacs -nw.I second the vote for `make-frame-on-display`...
I don’t see how you can justify using screen+terminal over X11 in terms of ugliness. Terminal is no beauty. And memory? Who cares? That argument has been dead for a decade.
Except Apple’s Terminal.app can render fonts nicely and I’m not sure how to get X11 emacs to render nice fonts.
But thanks for the suggestions. I’ll look into it. Change is sometimes hard to accept.
I like using GNU screen myself in order to work on remote machines. The only think that really aggravates is the following: In Terminal.app use ssh to connect to a remote system (all of them running GNU/Linux in my case), run screen on the remote end, and notice how backspace no longer works. And I haven’t found a way around it.
Worse than that (and I think this is a limitation of the Mac keyboard input system) Terminal.app doesn’t forward modifier key combinations properly. This prevents me from doing things like C-M-x and M-%. Also, I can’t get my function keys to send properly.
However, for your specific problem with backspace, I think I solved it by copying over my Mac’s
xterm-colortermcap entry to~/.terminfo/x/xterm-color.Not sure where ugly comes into the picture. If you turn off scrollbars, the menu bar, and the toolbar, then the only difference between Emacs in Screen and Emacs in X is the number of colors it can use. That and the fonts; I don’t know what the font situation is like on Macs. I know the terminal emulator is probably capable of displaying more fonts, but it’s just a matter of picking one you like in X, which is usually not difficult. (For me that’s Terminus.)
The other main advantage of make-frame-on-display is that it allows each user to have his own cursor and window configuration. If you adhere to strict protocols in your pairing this may not be useful, but I do appreciate this extra flexibility.
Oh, and also X is capable of recognizing a much broader variety of keystrokes. Emacs in a term session just gets constrained by the range of control characters it can grok. It’s handy to not have to worry.
Now that mtty has been merged you can even have one user in screen and the other using X according to his preference.
Hm… I don’t know enough about termcap and terminfo and all that. I see that there is a /usr/X11R6/lib/X11/etc/xterm.termcap on my Mac, but it is unclear to me where and how to copy the xterm-color entry (the remote GNU/Linux machine where I run screen?) – and why settings for xterm should affect the readline library that bash is using.
Inside Emacs I solved the problem! I open Terminal.app, ssh to the remote box, start GNU screen, start Emacs, and in my ~/.emacs file I have (global-set-key (kbd ““) ‘backward-delete-char). I think that’s the setting that fixes my problem.
Actually, now that I’ve started wondering about that line from my Emacs init file, and reading the Bash man page again, I discovered that adding RUBOUT: backward-delete-character to my ~/.initrc also worked. Since I rarely use anything else, I might have solved this problem!
Uhm, I don’t know what I was testing when I wrote that last message. Some “od -c” love showed me the way:
”\e[3”: backward-delete-char ”\e\e[3”: backward-kill-word
In your ~/.inputrc…