Noel Rappin Writes Here

We hope that 1 + 1 = 3

Previously on Locally Sourced: I’ve been doing a lot of these oddly titled posts about XP and Agile practices. Like testing. Or OO. I wrote about inclusion on agile teams. And about team metrics. Next up: pair programming. And even though it sounds a little pretentious to my ears, I really do think this is going somewhere, and I think between the last one and this one, the shape of the argument is starting to make sense to me.

Hey, if you like these posts, tell a friend. If you really like them, consider subscribing. I think I know what the first subscriber-only feature is going to be (it’s going to involve Rails, Stimulus, and SCSS, and will probably pick up where https://pragprog.com/titles/nrclient/modern-front-end-development-for-rails/ leaves off). But what I’d really appreciate is if you comment here and let me know what you think of all this. Thanks!

Pair Programming has, I think, been popularized in a somewhat unique way among the XP/Agile practices. Here’s how Kent Beck writes about it the original XP Explained book:

Pair Programming really deserves its own book. It is a subtle skill, one that you can spend the rest of your life getting good at.

Both of those sentences are interesting.

On the one hand, nobody ever wrote that book. That’s not completely true, actually. Amazon tells me there’s a book called Pair Programming Illuminated and I’m sure it’s excellent, but it came out on 2002, is currently out of print, and I was buying XP related stuff left, right, and center in 2002, and I somehow don’t think I ever read this one. (Though it does sound familiar).

And we don’t treat pair programming as it’s own skill, either. I’ve done this rant before (https://noelrappin.com/blog/2018/06/pair-programming/) and I don’t want to totally repeat myself. For our purposes here, the main point is that we assume that we can just throw any two developers together for an hour to work on a bug, call it pair programming, and therefore get a huge benefit out of it.

That blog post I link to lists a bunch of logistical things that need to be in place for your team to pair effectively. (The only one I’d change now is remote – you can do a full time remote pair, just 2018 me didn’t quite realize it.)

Beyond that, however, pair programming is actually a skill, and it’s not one that anybody teaches. It’s different than programming on your own, and it’s different from trying to teach somebody about a domain by having them watch you program.

How is it different? Well, with the disclaimer that I don’t think I’m very good at pair programming, here are some features of good pair programming:

• Good pair programming requires you to be able to articulate why you are doing what you are doing (though over time if you work together often enough, a pair should get a sense of your working style.)
• Good pair programming requires focus. My own personal style on my own is somewhat unfocused, and I find especially long pairing sessions to be uncomfortable. (I’ll often try to negotiate breaks.)
• Good pair programming requires you to be somewhat flexible in your choice of tools. Trying to explain your idiosyncratic Vim setup to your pair is not the best use of your time.
• Good pair programming requires you to be able to delegate and split the tasks. A really good pair session has control continually moving back and forth between the developers. (This is still super hard to do with remote tools, and much easier if you have dual keyboard setups).
• Good pair programming requires you to listen to what amounts to a continuous code review. And it requires you to be comfortable showing your first attempts at solving a problem even though – especially though – they are not fully formed.

Pairing is hard. The only structured plan for how to pair that I know of that has any kind of popular awareness is ping-pong pairing where one developer writes a test and the other writes the passing code. This kind of pairing is, if anything, harder that regular pairing. It requires a set up with fast unit tests and it requires a lot of comfort on the part of the developers who are pairing.

A little more to the point of this series, being a team that does full or even close to full time pairing places a very high bar on your team’s level of inclusion and comfort with each other. In order to pair regularly, every person on your team needs to be comfortable working one-on-one with every other person on the team. This is a strong level of comfort.

In the original Beck says “What if two people don’t get along? They don’t have to pair”, by which he means they don’t have to pair with each other. Then “What if somebody refuses to pair? They can choose to learn to work like the rest of the team, or they can choose to look for work outside the team. XP is not for everybody, and not everybody is for XP.”

What’s interesting about that, and which goes to my general point about the original XP/Agile work, is that Kent does not consider “What if somebody is such a jerk that nobody wants to pair with them?” or “What if the team makes an engineer feel so bad that they don’t feel safe or comfortable pairing with anybody on the team”. Both of which seem quite plausible in the real world, and neither of which XP has any kind of answer for. Mostly, it seems, we solve those problems by not pairing.

What we do, it seems, is to sort of aspirationally say that we should pair, but provide no real support for doing so, let alone for doing it well. This leads to people trying pairing, having a bad experience because of the lack of support, and then giving up, but feeling vaguely bad about themselves for not having done it correctly.

And it’s not even that I think pair programming is a magic practice that will make your team unbeatable. To be clear, as with just about everything else, there’s not a whole lot of evidence to support pair programming, and there’s not a whole lot of evidence to deny it. Unlike other XP/Agile practices, I’ve had fewer positive pairing experience, so it’s a little harder for me to give pairing the same kind of advocacy that I would for, say, TDD.

It seems that there’s are strong parallels here between pairing, testing, and strong forms of OO, where the value is hard to see in a small sample, they are hard to do, they often don’t work well if you just dip a toe in, and this all leads people to abandon them or to find something that is sort of adjacent but much easier to do in a less formal way. For pairing, that’s the “you can pair if you want to”, which tends to give none of the potential benefits of pairing, but brings frustration and at least some of the potential costs.

Does this match with your experience? Is there some outstanding guide to pairing that I’m not aware of?

Next time: The next entropy essay explains why I’ve been calling them entropy essays. I think there are two or three more in this sequence.