Pair Programming with VNC

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

A little Agile to go with the Ajax…

My four commandments of Agile Development are:

1. Short iterations
2. Pair programming
3. Test driven development
4. Continuous improvement (sprint reviews, etc.)

I have strong opinions about continuous integration and related agile practices, but those can be negotiable. Not all methods are appropriate for all teams, projects and clients. But the four above allow each team to find its own velocity and process.

Offshore Pair Programming

But how to do pair programming with an offshore team? There are a number of inherent problems with making this work:

• Not enough schedule overlap with places like India and the Philippines
• Uneven network performance
• Language difficulties
• Telecom difficulties

None of these issue is insurmountable. If you are offshoring significant software development, you likely operate at a scale where you can afford decent bandwidth, firewalls and telecom systems. Don’t skimp here by trying to run Skype on already overloaded laptops. Give each onshore and offshore developer their own direct dial number.

For the schedule overlap, I’ve found that a 4 hour overlap is sufficient, though 6 is better. For a twelve hour time difference, one team can stay late while the other gets in early. Onshore and offshore can alternate on who gets in early, etc. Or you can go with the former Soviet Union (FSU), which has less of a time difference.

Finally, language difficulties can be a problem whether you are practicing pair programming or not. Rather than exacerbating the issue by placing an emphasis on verbal communication, in my experience it actually improves communication  between team members by getting them more used to one another’s accents. Immersion courses work for teaching foreign languages, why should it work for the less difficult task of understanding a foreign accent?

How to Pair

Now in an onshore setting, my company rarely practices the “one mouse, one monitor, one keyboard” brand of pair programming. Tasks are shared, the developers sit at one desk and collaborate, but they have their own laptops. This differs a bit from the traditional definition:

Pair programming requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: for example, while one types in unit tests, the other thinks about the class that will satisfy the test.

The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.

But in an onshore/offshore situation, where the partners are tied together by a phone line and a VPN, the shared workstation is really the only feasible way to make pair programming work. Anything else, phone, IM, email, even video conferencing, is awkward and unproductive.

In my firm, we’ve tried various approaches to shared workstation pair programming, such as Windows Remote Desktop, but we’ve come back to the one that performs the best and presents the fewest obstacles: VNC (Virtual Network Computing). VNC basically gives you remote control of a desktop. That’s from and to pretty much any Windows and Linux/Unix/X11 machine.

We’ve tried the approach of having one developer hooking up to the other developer’s laptop, but that leads to poor performance. A far better approach is to use a powerful server class machine and have both developers access it via VNC’s screen sharing. The idea of using a powerful server pairing station is nice. It recognizes that running something like Eclipse or Visual Studio, and application server and VNC is somewhat too heavy a task for a humble laptop.

Combined with periodic offshore/onshore personnel visits — which build up trust between developers — the shared workstation model of pair programming is something I would encourage anyone combining onshore and offshore development teams to try.

References

• RealVNC works great for pair programming
• The Chicken and the Vine: Trans-Global Pair Programming
• Distributed Extreme Programming (XP) Planning on AgilePlace
• Distributed pair programming: An empirical study

Technorati Tags: agile, pair programming, vnc