Engineering Blog

We pair program a lot at Rally, and I did it a bit before joining Rally. I’d like to share some of the patterns I’ve observed in the way people pair, and offer some suggestions about how to get better at it. This isn’t a talk about pairing setups, because our former colleague Rod covered that pretty well in a recent post of his.

To be clear, this is not based on any sort of industry research or anything like that – it’s just based on my experience. There are a bunch of commonly cited advantages and disadvantages to pair programming, from constant code review, less bugs, and enhanced productivity to tying up two developers for a single developer’s job. Those are all true of all the patterns I describe, but each pattern has its own strengths and weaknesses.

Oh yeah… these are in no particular order.

1 – Distributed Pairing

I did this a lot in my last job. Our work environment wasn’t opposed to pairing, but it also wasn’t set up for it. At best, we could have done the level zero pairing from Rod’s post. Often, I’d take a screenshot of code and paste it into the IM client we used and send it to a colleague across the building or on a different floor. I’d type whatever contextual information was needed, and he’d respond over IM as well.

This is not ideal. You can’t see the same screen or edit the same file. You can only communicate as quickly as you can type and read. Perhaps most importantly, you can’t read the body language of your pair.

2a – Teaching by Pairing (learning the craft)

This is pretty common, especially at Rally. We have a broad range of developer skill levels, from interns to experienced engineers. Pair programming is an excellent way to help developers advance their skills. By helping your pair work through a task, a problem, or an exercise, it’s possible to advance the rate at which your pair learns. It’s an excellent way to teach design, testing, or a new language.

2b – Teaching by Pairing (knowledge transfer)

Sometimes we learn while pairing despite not learning any fundamentally new skills. Knowledge of a new domain isn’t a skill, per se, but it’s an invaluable part of an engineer’s job. Pairing is an excellent way for two developers of any skill level to familiarize one another with a codebase or a project.

3 – Ping Pong Pairing

Ping Pong Pairing is a key part of both 2a and 2b. It’s also an important part of other forms of pairing. For those who don’t know, it involves one member of the pair writing the test and the other writing whatever implementation is required to make the test pass. By alternating between writing tests and writing the implementation, it allows both members of the pair to influence the direction the code takes.

Don’t like the test? Write a crappy implementation. Don’t like the implementation? Write a test that breaks it.

As the name would suggest, Ping Pong Pairing can become a game. Challenge your pair by writing the simplest, stupidest code possible to make the test pass. Make them write good tests and they’ll make you write a good implementation.

4 – Real Distributed Pairing

The remote pairing I described above is lame remote pairing – incomplete remote pairing. It isn’t even really pairing. A better setup for remote pairing involves screen sharing on similarly sized monitors and a good audio connection. As important as anything is that the audio can’t be over monitor speakers and microphones, especially at Rally. Our engineering area is nothing if not noisy. Because your pair isn’t there to see you and body language and because monitor microphones pick up all sorts of ambient noise, it’s especially important to have a headset with a good microphone. Such a headset will isolate what you hear to your pair’s voice, and vice versa.

You should always pair in person when possible, but Real Distributed Pairing is a viable alternative for teams that are distributed either temporarily or permanently.

5a – Story Pairing (short running)

For short-running stories, it makes sense for a single pair to carry the story from start to end. The level of ramp-up needed to bring a new member of the pair up to speed is often more cost than benefit for small stories. Subsequent changes to the same code can benefit from knowledge sharing pairing (2b).

5b – Story Pairing (long running)

For long-running stories, it is often beneficial to have one or two team members involved throughout the life of the story. When I say that, I’m assuming a team of 5 or 6. Having one or two key people who understand the direction a story is heading and who are responsible for driving the story to completion helps keep the story on track. Rotating the other member of the pair regularly helps to distribute knowledge. This is really just a specialization of 2b.

Pairing is a valuable tool in the developer toolbox. Understanding the many ways it can be applied is crucial for realizing all of the potential benefits. In a future post, I’ll talk about some of the ways pairing can become toxic. There are as many Pair Programming Anti-Patterns as there are Patterns.

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.

I’m a horrible artist. I’m so incredibly bad that it’s comical. It’s funny because when we’re in retros, I’ve taken to drawing caricatures of the members of my team. It has become a kind of running joke. When I say “the members of my team”, I’m including myself. When I drew my own caricature, I was wearing a Dropkick Murphys shirt, I was holding a keg of homebrew, and there was a computer with a broken mouse in the background. DKM and the keg of homebrew are topics for another post – for now, let’s focus on the evils of the mouse.

The mouse is a great tool for first person shooters, Photoshop, and surfing the web. That’s it. Even in Photoshop, people use it too much. It should only be used for controlling the brush or dragging a selection – you can and should change tools using the keyboard.

As a developer, the keyboard should be your best friend. The mouse robs you of more productivity than you can possibly imagine.

The first logical place you can ditch the mouse is in your IDE. Regardless of your IDE, you can leverage the keyboard. If you’re lucky enough to be using IntelliJ or Visual Studio with Resharper, then you can almost completely eliminate use of the mouse. Find a cheat-sheet with the keyboard shortcuts for your IDE of choice and keep a printout of it next to your computer.

Even with the printout next to your computer, it can be easy to fall back into using the mouse if it’s your habit. I have the perfect solution – get rid of your mouse. One of my teammates started with us in January right out of school. We were pairing one day and he was using the mouse often enough that I thought I was going to be ill.

Me: “Hey Eric, can I see your mouse for a second?”

Eric: “Sure, here you go.”

Me: “Sucker.”

It was a wireless mouse so he handed it right over. I promptly put it well out of his reach. He struggled at first but with a little coaching and lots of computer assistance, he was well on his way to keyboard-ninja status in no time. A few hours later, we needed a third developer’s help with something. He asked Eric if he could take over for a second. Eric moved out of the way. He quickly noticed there was no mouse.

Rod: “Where’s your mouse”

Eric: “Ryan took it.”

Rod: (amidst delirious laughter) “What a dick!”

The computer assistance I mentioned above was twofold in this case.

First, if you forget the shortcut for something when working in IntelliJ, on a Mac you can press Command + Shift + A. A box pops up and you can just start typing the name of the command you want. IntelliJ will show it to you along with the shortcut. I don’t know what the equivalent shortcut is for IntelliJ on Windows or Linux, but I’m sure it exists. You can probably find an equivalent command in Eclipse, too. When you know that one key combination, it makes learning the rest easier.

Next, when you are pair programming you can leverage something like KeyCastr on the Mac or KeyJedi on Windows to broadcast the keys you are pressing to your partner. This is invaluable when pair programming with someone who is over-dependent on the mouse. It can also be really helpful when doing projector sessions that involve code. You never know when you might learn a new shortcut, even if you’re familiar with your IDE of choice.

Not everything on the web has to be mouse-centric, either. You can (and should) enable keyboard shortcuts in Gmail. I think they’re on by default in Google Reader. My last hackathon was spent adding them to Rally. I’m not sure when that will see production, but I’m going to fight to get it there.

The keyboard is your friend. The mouse is your enemy and it robs you of more productivity than you know. Take away your own mouse for a day and see what happens.

Happy keyboarding!

Rob Park and I will be hosting a CodeRetreat at Rally on March 27th.

What is a CodeRetreat (taken from the CodeRetreat Ning site)?

At CodeRetreat, we retreat from the world to advance in our craft. We sharpen our saws, together. We retreat from production and business value to increase our production capacity, our quality, our velocity, our ability to produce business value. We retreat from immersion in deep technology weeds (Oh no! The JBoss ClassLoader is giving me CCE’s!) to advance in our ability to learn and adopt to any technology well. We retreat from our fears, and embrace new practices, patterns, languages.

We retreat from our local ponds and swim in a larger pool. We connect with other passionate coders who we seldom get to code with. We make new connections and learn new lessons.

Code Retreat Format

• Problem: Conway’s Game of Life
• Length of Iterations/Sessions: 45 minutes
• Duration: 8am to 5pm
• Language: Java

This will be a fun day for all. Breakfast and Lunch will be provided. If you will be attending, please register at http://coderetreat.ning.com/ or send me an email at aesterline at rallydev dot com.

What’s it like to be a software engineer at the best medium-sized company to work for in Colorado?  Well, it’s quite awesome actually.

Allow me to give you some perspective on where I’m coming from: I started at Rally three months ago, I’m fresh out of college (University of Colorado, Computer Science 2009), and this is my first full-time permanent job.  Additionally, I’m at least five years younger than all of the developers here so I’ve definitely heard my fair share of jokes about my age over the past couple of months.  Despite this “abuse”, I’d like to reveal some of the reasons why I feel the engineering team here is so productive and why it is so great to work here:

1.  Collaboration and Knowledge Sharing Throughout the Team

Knowledge is spread through the team constantly through many different mechanisms such as pair programming, daily stand-ups, and “Old Man Walks.”  I had never been involved in a successful implementation of pair programming before coming to Rally; I’d tried it out in a few classes but it just didn’t work for various reasons.  However, here at Rally it is taken to higher, way more successful level.  An example of this is what we call “Ping Pong Programming” – one person writes a failing test and it’s the other person’s job to write the simplest code to make the test pass.  I’ve noticed that this really helps keep both programmers involved, and thinking about both the design and implementation.  Additionally, we switch pairs at least twice a day which makes the knowledge sharing so prevelent that it is pretty much possible to ask any member of the team a question about any of the stories from the iteration and they will most likely be able to answer it.  Another activity that our development team frequently partakes in are what we refer to as “Old Man Walks”: the majority of the team gets up and goes on a 20-minute walk around the building discussing various work-related and non-work-related issues.  In my experience with programming, sometimes I just need to stop thinking as hard as physically possible about a problem before the best, most viable solution will come to mind and that is what old man walks allow for.  In addition, they naturally provide a environment for knowledge transfer and team building – everyone on the team is together, discussing the same problem and working towards a solution.  If we come to a consensus on a solution, everyone on the team will have heard the solution and will at least have some basic knowledge about the implementation should they need to work on the same topic in the future.

2.  Trust

There is an enormous amount of trust put in the development team from the management team.  This is exemplified by the fact that we as a development team determine how much work we are going commit to get done each week.  Another example occurred a few weeks ago during a Release Planning meeting.  The developers mentioned that we’d like to add a few weeks to the beginning of the coming release to complete some technical debt work that we’d started earlier before we could continue doing feature work.  After some discussion with the management team, our request was granted and feature work was put off for a couple of weeks while we worked on technical-debt tasks.

3.  Everyone (and their opinions) are important

…and the fact that the most inexperienced member of the team (me) feels this way further proves how true this point is.  Here at Rally, we have a system where every week, a randomly-chosen developer is responsible for handling any customer-reported defects and fixing other known defects.  We call this position the “Developer of the week”.  I was the developer of the week after working here for only two and half months.  Sure, it seemed like I was “getting thrown into the fire” a bit, but the fact that I was entrusted with this responsibility was really a confidence builder for me.  Another example of this occurred just a few weeks ago, as I was asked to interview a prospective employee that was applying for the same position as myself.  The person I was interviewing had graduated from college when I was finishing up sixth grade, yet I was given the opportunity to decide whether I felt he deserved a position at Rally.  This was so cool for me, to the point where I asked the candidate a JavaScript scoping question that I’d gotten correct during my interview (which I was told was uncommon for that question), and was called out by my interviewing partner as being “a little full of myself”.  The next day, I was asked (along with the approximately ten other developers that had interviewed the candidate) my thoughts about the interview and whether or not I felt that he should be hired.  Everyone’s opinions were considered before the final decision was made.

4.  Freedom to be creative

At the end of our eight-week releases, we always have one week (called “Hack-a-thon week”) where the developers can work on anything that they think will benefit the company.  Do you realize how awesome this is?  During my first hack-a-thon week, I was actually a little bit caught off guard by this newly-found freedom.  Throughout my educational and working life, I’d always been told what to work on.  I had never been given the opportunity to add any feature or do any modification I pleased to an existing, large application.  I was essentially a kid in a candy store.  Many of the popular features in our application have come out of work done during this week, so it is evident to me that allowing smart people to be creative and innovative is a great idea, for both developers and for managers.

5.  Work environment

The work environment at Rally is truly something special.  Those closest to me know that I consider middle school as the greatest period of my life thus far.  Well, the environment at Rally is actually similar to the environment found in a middle-school classroom… and this is probably the best compliment I could ever give to a workplace.  Remember how I mentioned in my previous point that I was a “kid in a candy store”?  Well, that is actually a good description of my daily experience at work; there is almost always at least some free candy and/or free food (not to mention the on-site kegerator).  Additionally, all of the developers work in the same area so this provides the perfect environment for good-natured joking as well as the collaboration that I discussed earlier.  We always incorporate a couple of fun activities into the eight-week grind of each release.  This release, we played kickball which is something I hadn’t played since middle school, and I came out of it with a further appreciation for how having fun can have such a positive impact on productivity.  Oh, and we usually try and get at least one foosball game in a day so if you think you’re a foosball prodigy (like I once claimed to be), prepare to be humbled.

We’re hiring!  So if you’re lucky you might get interviewed by me (here’s a hint: know your JavaScript scoping rules ).

Many of us at Rally like to Pair-Program because it offers continuous code reviews and many other benefits. We also like using Git, because it’s fast and makes branching and merging far easier than Subversion.

Unfortunately, pair programming can often make interacting with a version control system difficult. Who officially makes the commit? How do you make sure the other half of the pair gets credit/blame when needed?

Luckily, Bryan Helmkamp wrote a script that allows pairs to update the usernames of commits to reflect the involvement of both people.

We’ve been using this script, but we’ve made some changes and figured we’d let others use the modified script as well.

(more…)