A couple of weeks ago, a colleague and I decided to give pair programming a try. Full stop, no holds barred, real-life, textbook (sorta) pair programming. This was the first time we had tried this experiment while I’ve been working as an Openrain ninja developer. My previous experience with pair programming comes from my time working on internal corporate web applications at Intel. We were both excited, eager and willing to give this experiment our full attention, in order to find out first-hand if the benefits could work in our particular development environment.

What we found over the course of one week of developing full time as a pair was interesting. Of course, our “findings” are based entirely on gut feel, although we did have a list of closed issues in our tracker that helped give us something to measure.

Our pairing time seemed to go through many of the typical phases of team formation, forming, storming, norming, and performing. Day 1 was a little uneasy, since even though we were eager to try it out, there was still a little uneasiness on both parties. And, while we didn’t argue, per se, I’m sure we found small things about each other’s work habits a tad annoying. However, at the end of the week, we found we were able to get to several tickets, and were quite amazed at our progress.

One key issue that wasn’t address was that of the common development environment. We had decided to use my system as the development machine. We also decided to use RubyMine, a new rails development environment with promise, and one which neither of us were familiar. We didn’t have an ideal workspace, as this would be one of the key things I would like to see remedied if we are able to pair more consistently.

One of my favorite features of pair programming while at Intel was the opportunity to learn the abilities and personalities of your entire team. My team had started off with 15 members, and was split in half after deciding it was too large. Even with 8 team members, I found pairing to be extremely rewarding and helped me to learn at far greater a pace than I would have on my own. Our current team is a bit smaller, consisting of me and my colleague. I still found our pairing time effective, however, the team member swapping will always be my favorite part of pairing.

One point of concern that seems to appear while pairing is the passenger boredom during certain technologies. We seemed to both agree that pairing while writing Ruby and Rails code was effective, fun and rewarding (my words, not his). However, when it came to CSS, Javascript or other non-ruby code, it was obvious that we had not found the most effective way to pair with that particular code.

Overall, I found it refreshing to be able to continually learn more subtle aspects of rails and how to author code the ruby way using pair programming. I hope that Openrain will be able to find more pairing opportinuties, and that we address these shortcomings, because despite them, I found that week to be very effective, productive and rewarding.