How we work - Pair Programming
Sep 3, 2015Pairing is a big part of how we develop software at Influitive. We’ve been pairing nearly as long as the company has been around, and it’s had a huge impact on the quality of our code and how we work together as a team.
A brief history
Despite taking a lot of inspiration from the Extreme Programming movement at Influitive, early on pair programming seemed like a bizarre ritual practiced by zealots who were a bit too interested in the “extreme” part of pair programming. It’s a seriously counterintuitive thing to get your head around - obviously reducing the amount of “hands on keyboards” by half has to carry some cost in terms of productivity. We bought into the idea that quality would probably improve, but early on in the company’s history that was less of a concern - we were more tuned to moving fast and breaking the occasional thing than ensuring high quality at all times.
At the same time, we were seeing some amazing success from other companies like Extreme Labs (now Pivotal) pair programming religiously. We tried experimenting with pairing now and again, encouraging developers to pair when they were working on something particularly difficult. But it wasn’t really clicking.
We decided to try an experiment.
Like a lot of companies working in an “agile-ish” environment, we track the velocity of our teams against story point estimates for what we’re working on. We wanted to understand just how much productivity loss we would actually encounter from pairing 100% of the time. We decided to run with it for a month. Because our estimates were made before this experiment was even proposed, we figured it would truly represent how much pairing slowed us down.
After our second week, something incredible happened.
Our velocity was exactly the same as it was when we had developers working independently. We were moving just as fast with pairing as we had been without, and there was a far better understanding of each other’s work, and a significant uptick in quality. We quickly joined the ranks of the zealots.
Pairing today
We’ve learned a bit about pairing in the 4 years that we’ve been doing it, and our opinions and philosophy about pairing have evolved. While we definitely went through a period of pairing in 100% of circumstances, we refined our thoughts around when it makes sense to pair.
Today, we like to think of our approach as “your default assumption is to pair.” Many companies default to individuals working alone, and pairing when they’re working on complicated things. We started that way, and we learned fairly quickly that pairing is a skill that needs to be practiced, and that logistically it’s hard to find a pair partner when everyone’s used to working alone. If I have a good reason not to pair, I absolutely won’t, but in the absence of that, I’m working with another developer.
Another circumstance where we learned pairing isn’t always a silver bullet is with newer developers. While pairing can be great for working with someone more experienced and learning from them, a large part of learning is about discovering things yourself, and it’s really easy to fall into a trap of letting the more experienced person drive, particularly when there’s a big skills gap.
Tips for making pairing work for you
Thinking of trying pairing? Great! Here’s some best practices we’ve encountered as we’ve learned more and more:
-
Pairing is a skill that needs practice - Don’t be afraid to be a little artificial and play “pairing games” like ping-pong when you’re starting out. They can seem annoying, but it’s surprising how quickly you can fall into bad pairing habits.
-
Pairing doesn’t really work if you have insane hours - Pairing is tiring. We’re big on having a reasonable work week at Influitive, but in the odd circumstance where we’ve had long days, the effectiveness of working in a pair seems to degrade far more than when you’re working alone.
-
Encourage pairing through your work environment - Two people huddled over a laptop is not going to be a fun experience for anyone. If you’re committed to pairing, strongly consider dedicated workstations with large screens, independent keyboards and mice - set up and ready to go at all times. Most of our developers do 90% of their work on dedicated pairing iMacs, with “floater” laptops around the office for any independent work that needs doing.
-
Remote pairing works surprisingly better than you think - This does require some setup - we use Screenhero, and invest in good quality headsets to keep the conversation going between the remote developer and the local one.
-
Experiment - Don’t take my word for it. Try it out yourself - run an experiment and see how pairing works for you.
Related Posts
-
Chain of Responsibility for web requests
A technique to optionally handle web requests in an extendable way Read More
Jan 19, 2016 -
Plotting data for the web
Using the D3 library to create dynamic plots Read More
Dec 1, 2015 -
Frozen_state
Command your State - Using commands and actions to modify your state Read More
Dec 1, 2015