Nerds in the Wild: Pair Programming

The Far Reach team spent over a year and a half becoming a scrummy organization, and we’ve learned a few lessons along the way. In this series, we’ll share what we’ve learned and give you a sneak-peek into a typical day at Far Reach. The previous post was about scrum poker.

A lot has changed—no, evolved—at Far Reach over the past nine years. One of which is our use of “pairing,” short for pair programming.

Pair programming, according to Wikipedia, is “an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed. The two programmers switch roles frequently.”

I’ll use the analogy of teaching someone to swim. Until just a few years ago, it was mostly “sink or swim” for team members at Far Reach. You got thrown into the deep end and you either swam or you didn’t.

Unfortunately, some of those who struggled left a mess in the pool, which required cleanup. The same holds true when you put an inexperienced developer on a project without the proper onboarding and training. Sure, they may get the job done, but they may produce code that is hard to maintain.  

Over the past two years, we have started to adopt agile approaches to software development, one of which is pair programming. I would say we are in the infancy of pairing at Far Reach.

We don’t pair 100% of the time. Why? Because we constantly strive to provide the most value to our clients. At this time we don’t feel having two developers pairing with each other full time provides the most value.

Here are some scenarios where we have decided to pair as much as possible:

• Complicated user stories – There are user stories that are highly complex or have a lot of risk. Last year we had one story a developer was working on for several days and was having a hard time implementing the chosen approach. Unfortunately, the approach wasn’t going to work, so the two of us came in on a Saturday and cranked out the story in about five to six hours. Multiplied by two it was still less than the 20-24 hours already spent on the story. In this scenario, the story of the Belgian horses held true: “One of the largest, strongest horses in the world is the Belgian draft horse. Competitions are held to see which horse can pull the most and one Belgian can pull 8,000 pounds. The weird thing is if you put two Belgian horses in the harness who are strangers to each other, together they can pull 20,000 - 24,000 pounds. Two can pull not twice as much as one but three times as much as one. This example represents the power of synergy. However, if the two horses are raised and trained together they learn to pull and think as one. The trained, and therefore unified, pair can pull 30,000 -32,000 pounds, almost four times as much as a single horse.” Dave Ramsey, Entreleadership
• Technical analysis – Design decisions made early in a story have a direct impact on quality. We have a lot of talented developers at Far Reach. We all have different experiences and have tackled many coding scenarios over the years. That’s why it’s important to get other developers’ perspectives. They may have insights that could save a developer significant time on a story—thus freeing the developer up to work on additional features for the client.
• Training/Onboarding – We implement a lot of pairing when bringing developers onto a project or when a junior developer is working on a project.
• Code reviews – Developers will sit with the primary developer on a project and review the code in detail. Sometimes this leads to a paired refactoring session.

Other types of pairing:

• Backlog grooming – The PO has to balance the budget, scope, and timeline for each project. During backlog grooming, the entire team gets to ask questions and weigh in. This enables the team to maximize value to our clients.
• Tester/Developer – Developers have a tremendous amount of insight into what to test in an application. There are many times when a developer will sit down with the tester and work through the complex test cases.
• UX designer/Developer – A designer will sit down with a developer, and they will walk through the story and pair the UX. Sitting with the designer, the developer is able to help the designer understand the impact design decisions have on budget, scope, and timeline. You would be surprised how the smallest design decision can significantly increase the effort on a story.

 The results:

• Fewer “oh crap” moments when a story goes significantly over budget ­– Pairing the risky and complex stories mitigate the risks that lead to the missed estimates. Pairing the technical analysis also helps prevent these issues.
• Eliminating the “hero” at Far Reach – The “hero” is one developer that has all the knowledge of a system. This is also referred to as the towers of knowledge. Pairing allows us to distribute that knowledge to other team members.
• Reduced stress and additional flexibility – Being the “tower of knowledge” means you never really get to go on vacation, or if you do, people have to hope nothing happens while the tower is away. It also makes resource planning and customer support difficult if only one team member knows a system. That is not fair to our clients, our team, or ourselves. I never thought of it that way until I read “Joy, Inc.: How We Built a Workplace People Love” by Richard Sheridan. Thank you, Richard! We have just started tearing down the towers over the past three months, and the results so far have yielded great returns.
• Better quality and value – We haven’t formally measured this, but it sure feels like we’ve reduced the number of bugs found during testing. I also think developers step up their game when they know they’re developing code others are going to review and support. I totally buy into this image I saw on the “C# Corner” on Facebook.

• Team “gelling” – Since we’ve been more intentional about collaboration, the group feels and functions more like a team. Team members are less concerned about individual progress and more about the team’s progress. I refer to the story of the Belgian horses. We are getting more done working as a team than we were by dividing and conquering.

While we aren’t implementing “pair programming” in its truest form, we have made tremendous progress in creating a highly collaborative environment that’s generating value to our clients. I can’t wait to see where we are next year.   

We constantly strive to improve at Far Reach. I’d love to hear about your approach to pairing. I’d like it even more over a Pablo’s burrito. If you’re ever in the Cedar Valley, reach out to me and I’ll treat you to lunch.