On Friday I had a pretty fun conversation about software development with a fellow developer. He works at a financial institution and, when we talked about things like TDD, Agile, XP, etc., he had mixed feelings. One of the topics he found most controversial was precisely pair programming. His opinion basically boiled down to one sentence: “what I don’t buy is that two senior guys sitting together to code are going to be more productive than if they code separately”.
So I decided to write a post with my opinion on the subject and share my point of view (even if nobody cares xD).
Background
I love coding alone. I really enjoy sitting at the keyboard while I take on a technical challenge or look for a design approach that convinces me. I also love spending hours reading code from open source projects to see how other development teams do things. I enjoy building code generators that generate code to generate code generators. In short, I love diving headfirst into anything related to software development and losing track of time.
But liking it doesn’t mean I think it’s the best option in a professional context. Software development isn’t just my profession, it’s my hobby. That’s why I do all these things I like mostly in my free time and, when I’m working, I decide what to do based on what suits the project best.
I’ve been working for a little over a year on a project where we do a lot of pair programming, so I can’t say I’m a veteran at this, but I think enough time has passed to have an opinion based on experience.
The good
For me, the most interesting upsides of this practice are:
- It favors collective code ownership.- It helps get rid of the “so-and-so wrote that and only he can touch it” effect. If on top of pair programming we add rotation within teams, the benefit is even greater.
- The code is better.- Nothing like 4 eyes watching the code being written. At the very least, it guarantees there has been consensus between two people on the readability, design and structure of the code.
- The tests are better.- I can hardly remember a pair programming session where, out of the dialogue between both sides, some triangulation test to cover an edge case didn’t come up.
- It encourages defining and using the ubiquitous language.- When you code alone you pay less attention to names and, even if you do, you lack something very important for finding the most suitable name: debate.
The bad
Like everything, it also has some downsides. For me these are the main ones:
- It’s hard to do it right.- Anyone who thinks pair programming is just two guys sitting side by side and swapping the keyboard is way off. At the end I’ll add some links with tips on this.
- Fatigue.- Yes, 4 hours of pairing are really tiring. Even more if it’s not done well. A tip: it’s important to respect breaks or your brain ends up fried.
When?
That said, I don’t think it should be done 100% of the time either. I think this practice adds a lot of value when we’re writing business code and much less when we’re talking about UI and infrastructure. When we’re dealing with domains we’re still exploring and it’s clear the bottleneck isn’t going to be how fast we type code, that’s precisely one of the scenarios where this practice will give us the most benefits.
I don’t usually find it practical to use pair programming to write infrastructure code or the code of a view. Unless we’re mentoring, but that’s another story.
Of course, there are always exceptions and we already know the answer is almost always “it depends”.
More information
A lot has been written on the subject, but these two posts are fresh in my mind, and they link to a bunch of others: