Engineering Blog

I started as a software engineer at Rally about 2 months ago. I was initially excited about Rally because of the agile philosophy and the perks of living in Boulder, but I became apprehensive after I learned that Rally uses paired programming extensively. I was coming from an environment where I worked in a private office. Rally’s engineering area doesn’t even have cubicles. Could I handle the pressure of other developers peering over my shoulder as I write code?

My fears were quickly eliminated during the on-site interview. Rally’s ‘pairing stations’ consist of a shared computer, but separate monitors/keyboards/mice. Pairing stations are positioned at 90 degree angles, so it is easy to communicate with your pairing partner, but you never get that ‘reading-over-the-shoulder’ feeling.

The interview included a Java programming exercise, but I had never worked with Java before starting at Rally. Working on the exercise with my interviewer as my pairing partner, I would express the logic I wanted to implement, and she would show me the correct Java syntax and tell me about the different data type objects available in the Java standard library.  It worked surprisingly well. We developed the prototype together, and pointed out errors in each other’s code. By the end of the exercise we had a working prototype with tests, despite the fact that I hadn’t ever coded more than 50 lines of Java.

Since I started at Rally I’ve learned that the main advantage of paired programming is a huge boost in code quality, and is especially helpful when learning an unfamiliar code base. The sum is greater than the parts, and paired code gets the best design and implementation possible. Paired programming serves as a ‘real-time’ code review. Bad design decisions, typos, and bugs are often caught before compiling or running any tests.

Some developers may be concerned that paired programming is too resource intensive, since 2 developers are assigned to work on a single task. However, I believe productivity is the same or better than solo development, with better overall quality. Engaging discussions with your pairing partner reduces the tedium of repetitive tasks (yet another CRUD form…), and I find myself seeking diversions from work (email, reddit, snacks) less often.