Do you work in an environment that doesn’t promote pair programming? Or worse, it’s not even allowed? Or do you find yourself in a highly productive and positive environment, which really wants pairing to thrive? Perhaps you are already experts in pairing and have formalized a process around it? No matter the situation, I guess you are reading this post out of interest of boosting your pair programming.
Remote! what? NO!?
I guess the title immediately hits most of you seasoned agile practitioners with an alarming red screaming alert; anti-pattern, anti-pattern. Yes, not long ago, I would have agreed with you on that thought, until recently when I actually tried it for myself. First, let’s go over the short story that led up to our remote pair-programming session, and then take a look at the positive effects and how it may boost your pairing!
What on earth made us pair remotely?
A colleague of mine and I needed to get this feature done, which in itself wasn’t particularly hard, but it consisted of several tasks, some easier, some harder. We both had kind of an idea how to solve the feature due to each of us having previous experiences on the topic, and the fact we spent a lot of time in meetings discussing various angles to attack the feature in a way that would suit our platform.
The time had come to transform a very basic proof on concept that was already in place, to something great. We booked a meeting so we wouldn’t get disturbed, and locked ourselves up in a war room, joining forces for the duration of a day. We had a very nice session, indeed! We used one computer, hooked up to a projector which displayed the code all over the wall, we had whiteboards to model, discuss and test ideas. We started out by transforming the proof on concept implementation we already had, writing unit tests, deferring coding tasks etc., and all in all, it felt good. We did get far, accomplished a lot, and we ended the session with a smile on our faces after a great day spent together, and speaking for both of us now, looking forward to the next day, for us to continue in much the same way.
When we finally got around starting a new session the day after, my wife called and I needed to leave to get our daughter to the hospital, so the session ended before it had even started. We didn’t get much done that day, obviously!
Shame on those who give up!
Next morning, I decided to work from home in case I needed to go back to the hospital, and so did my colleague for other reasons. But, we decided to keep pairing no matter the distance, and we continued where we left off. We fired up a shared desktop and launched Visual Studio, in which we could both code at the same time. We also used our phones with headsets to be able to speak (we call for free within our company; otherwise we would have used something like Skype or similar products).
We went on pairing over the phone and this shared desktop, switching between driver and observer back and forth! It felt very naturally without having to use any kind of time boxing or clock telling us when to switch. At the end of the day, after about 6 hours of remote pairing we both actually felt that this was a very nice way of pairing, and it removed several of the impediments we often felt when pairing at the office.
What are the positive effects then?
These are the key areas we felt was boosted by a remote session compared to pairing in either co-located, or at our desks!
The feeling of a truly shared coding experience, it almost felt like I was writing code through my pairing partner. It doesn’t get better than that!
- Natural switching
At any point during our coding session, we could switch back and forth between driver and observer. It felt very natural, without having to ask permission, moving a laptop/keyboard or swapping chairs. We just started coding, and sometimes it brought laughter upon us, as silly things can happen with 2 keyboards and 1 Visual Studio.
- External distractions
We were working from home and I guess it was quite easy for us to avoid getting disturbed! But, had we been at the office and somehow communicated through our headsets I think we could achieve the same result. No one would interrupt a colleague that’s obviously on the phone, much too busy to be disturbed with questions or even a cheerful “Good Morning”! Having no external distractions allowed us to really enter this intense focus I think neither of us would be able to sustain working in our open-plan office.
- Internal distractions
Communicating over the phone, with our headsets, removed almost all internal distractions as there was no time, or opportunity to alt-tab into an email client, chat, twitter, surf, text or whatever people usually do during their coding. Out of respect, interest and a shared goal we were focused on one thing, and one thing only, together, which led to no task switching, what so ever.
Having breaks is great, and everyone really needs to have both shorter and longer breaks to be able to stay focused and keep working at a sustainable pace. Again, as we were on our phones with headsets, we could take short breaks and go get a drink or whatever we wanted and still remain focused. If I was coding, my colleague just took over while I was gone grabbing coffee and vice versa. For our long breaks we hung up and left our computer to get detachment which enabled us to come back really refreshed, ready for new endeavors.
All in all, I must say I was very pleasantly surprised after this full day of remote pair-programming, and I can only recommend it, no matter if you are beginners or experienced pair programmers. At least I will not even think twice before heading into a remote session again if the opportunity presents itself!
My colleague mentioned in this article, and also reviewer of this blog post, can be found on twitter as @perakerberg. You can also find his software quality blog here.