Love it or hate it, pair programming is a large component of many agile development methodologies. I’ve become a firm believer in the benefits of pairing, and very rarely write code nowadays without some degree of collaboration with a second (or third) developer. The benefits have been vast. The code is better thought out because a pairing session always starts with a discussion of the approach to be taken. Fat-fingered mistakes are headed off at the pass because a second set of eyes is closely watching what’s being typed. Less time is wasted checking email, taking calls from the in-laws, and just generally doing things that would annoy the second member of the pair. Above all, it allows developers to analyze and quickly debate the approach being taken, and adjust and improve that approach throughout the development cycle.
It all sounds great doesn’t it? Well it is when executed correctly. In my experience there are two general principals that if not adhered to, will turn a productive pairing session into a developer writing some mediocre code sitting next to a developer who might as well have taken the day off. These principals are: developers must remain engaged, and developers like their own space.
VNC (Virtual Network Computing) is a platform independent desktop sharing system that’s been around for close to 10 years. While any desktop sharing approach should work, I’ve found VNC, or more specifically TightVNC to be solid and stable, and more importantly FREE! As a team, we’ve started using TightVNC for pairing. One developer loads up the server, and one loads the client. Our desks are all close so chatting isn’t an issue, but we’ve used the same approach while working remotely using a headset and skype. You won’t need to tote your laptop around, and you don’t need to rearrange anything to accommodate another developer staring at your already meager amount of screen real estate. It allows for easier “tag-teaming” as nobody has to move to pass the keyboard. You simply stop typing and let the other developer have at it. The simple fact that a developer can easily see and participate in the coding process leads to a higher degree of engagement and more ownership of the code being produced. As a added benefit, this process works well for a sick co-worker that may have forced themselves to come into work, infecting your whole team with some dreaded illness.
Give remote pairing a chance, and see if it helps you overcome the annoyances that may have stopped you from embracing the practice fully.
Just last week I started doing this with my son, both as a fun thing for us to do together and as a way for him to learn, and it’s been *tremendously* successful for us!
We use RealVNC rather than TightVNC because we were never able to make TightVNC work over our network, but I’m sure it’s pretty much the same thing.
I actually find remote pairing to be far more convenient and productive than ‘desk pairing’, if for no other reason than the fact that neither person has to give up the physical environment we’ve grown accustomed to and which we have painstakingly adjusted to our own personal tastes over the years.
[...] programming – Check out my colleague Jason Pearl’s post here; I spent most of my day pairing with him today (and many other days) and the benefits are very [...]