On Sunday evening, Joseph Walker at the Wall Street Journal published an article belittling pair-programming and taking quotes out of context.
As co-founder and CTO of Mavenlink, I’ve been pair-programming with my team for nearly 4 years. I want to set the record straight.
A (somewhat) brief history
At my last job, we did a lot of custom software delivery and quite a few proof-of-concepts under incredible time pressure. Often, we would find ourselves behind on a complex project or getting into a sales cycle a little late. When that happened, many of us would drag together a couple of chairs and crank out some code. Other than group projects in college, this was my first experience with any type of pair-programming, although I didn’t know it at the time.
Ironically, due to social and management pressures, we only ever did it when there was absolutely nothing to lose and we just had. to. make. it. work.
When I left that job to co-found Mavenlink, we decided early on to use Ruby on Rails and started looking for an early-stage development partner. We found Pivotal Labs. During our project’s scoping (hi Davis and Rajan!), we talked about Pivotal’s general agile practices, XP, test-driving, and pairing. For us, at the time, pairing was a great way to get me trained up on their best practices. Little did I know that we’d spend the next 3 years working there and would hire our own team based on pair-programming acuity.
Why the WSJ got it so wrong
1) Pairing is not for everyone
I would never go into a company as a new engineering manager and tell everyone that they have to pair, full-time, starting right then. That makes no sense. If an engineering department or team isn’t structured around pairing from the get-go, it’s very possible that it simply wouldn’t work. Some people, and certainly some developers, just like to put on headphones and solve problems quietly on their own.
For better or worse, in our hiring, we look for people who fall on the social-side of the spectrum when they’re working on problems. Our interviews are specifically geared towards collaborative problem solving and we include a pair-programming component as a further check.
WSJ: Thanks for giving us one example of a company whose culture didn’t like pairing and an example of some guy who didn’t like it. What about all of the other companies and people who do?
2) Pairing, like anything else, is not about the ideal
In the ‘90s, many people considered Yoga pretty weird. If you did Yoga, you were probably “from California” or someplace oddball like that, right? Now, in 2012, Yoga has non-weird proponents everywhere who talk about the increase in strength, flexibility, and mental acuity that comes from regular practice. However, not everyone who does yoga looks like a pretzled Yogi.
Pairing is about collaboration, writing better code, teaching, and keeping each other in check. With some practice, collaboration and bouncing ideas around comes more easily, but not everyone is going to grunt ‘n’ code, as Kent Beck mentioned. You don’t stop doing Yoga because your hamstrings are still tight and you don’t stop pairing because you need to talk a little bit (or a lot).
WSJ: Thanks for taking Kent’s quote, using it as some freakshow article byline, and then sidelining him with “That’s the theory, anyway.”
3) Writing software, like building anything, is a team sport
The article paints a picture of overly-aggressive, smelly, bad-breathed, terribly-socially-matched people not being able to pair program. My question is: pairing or no pairing, are these people really able to work together AT ALL? Everyone has their quirks, but is the alternative to sit in separate offices with closed doors doing your own thing and expecting good results? What if a sports team did this?
If we’re going to take an extreme view on pair programming, that’s the other extreme: non-collaborative, opinionated, siloed work that comes out of one person’s head. In reality, nothing, including software, is ever built like that. There are status meetings, whiteboard sessions, scrum sessions, architecture meetings, and all the other checkpoints. All of these were invented to increase communication and collaboration between team members.
Pair programming and daily pair rotations help reduce the need for many of these meetings. If we all frequently cycle through much of the product, everyone has experience with the business’s parallel development tracks and every pair is able to make their own decisions around the day’s work.
WSJ: Thanks for the dating analogies to drive home your point. I guess it doesn’t matter that over 30% of traditional (non-paired) office workers say they have a “work spouse“…?
4) How rotations work in the real world
One traditional model is to build software separately, doing regular peer code reviews, and coaching each other. This can work well when an organization is extremely disciplined, but what often happens in reality is that every developer has 16 hours of code to write in an 8 hour day, so the last thing that they’re thinking about is someone else’s problem. Also, without context or a large time investment, how am I supposed to get my head around a problem that someone else has been working on for days? Time-strapped reviews often lead to surface-level re-factorings, but not to deep discussions and improvements.
With pair-programming, we’re live reviewing our pair’s ideas and constantly collaborating on a solution. Sure, it can be a little daunting at first, but you quickly realize that we’re all playing for the same team with the same goals in mind. Holding dogmatic views about how something should be done is not unique to engineers, nor is it unique to engineers who pair. By combining agile design techniques with constant communication and rotations, pair programming is a great way to iteratively come to consensus, rather than “throwing the cards in the air” and starting over after something is half built.
*WSJ: We’re so “promiscuous,” we rotate daily. Yeah, it’s hot.**
5) Lack of shared knowledge is a massive business risk (pay attention Mr./Ms. Executive)
Software developers are often hired into a very specific position to do a very specific piece of the product. Let’s say your product has widgets, dongles, and plugs. Well, it’s natural to hire a person who only ever works on widgets. Over time, that person becomes the “widget guy” and has most, or all, of the context on widgets. Whenever Susan in sales has a question about widgets, she calls the “widget guy”; when Joe in support has a customer with a bug, he calls the “widget guy”; and so forth.
Now, “widget guy” leaves the company and everyone is lost. Bugs take forever to figure out, adding anything is difficult, and the new engineer tasked with taking over widgets ends up unhappy and either pushes for a re-write (sound familiar?) or is miserable and also leaves. Pairing and regular rotations between pairs completely avoid this issue by allowing each team member to see the evolution of widgets, dongles, and plugs over time. Nobody is a silo. Nobody inherits terrible code.
WSJ: This is about running a good business. All businesses have people with quirks. Where’s the news in that? So long and thanks for all the fish (that go bad after 3 days)!
Countless other benefits
There are countless other benefits to pairing: fun, camaraderie, avoidance of distractions (Facebook, Twitter, etc), efficient training of junior developers, etc. The list goes on and on.
We know pair-programming isn’t for everyone, but we know it’s for us.
Posted by Roger Neel. Contact me at roger [at] mavenlink [dot] com or follow me @mavenroger