…but it’s definitely for me.

Will Sargent posted an excellent writeup of the issues he encountered pair programming. I’d like to respond to some of his points. His experience is his, and is inherently valid. I’d like to offer some thoughts, though, as a counterexample.

In general, I love pairing, and never want to give it up. I pair full time and that’s the way I like it. I end up soloing a couple of days each month, and I miss having a pair to help me keep the flow going.

I do have some issues with the full-time pairing lifestyle, chiefly that it’s harder to take breaks, both to refresh yourself and to attend to administrivia, such as email. It’s easy to just write code all day and let other responsibilities slip. But when I’m writing code, I wouldn’t do it any other way.

Keeping flow

I found that in order to pair, I had to act as if I was in a continuous meeting. I had to not just listen to my pair, but appear to be listening; I had to nod in the right places, repeat back what my pair said in active listening fashion. I had to pick the right moment to interject. I tried to model my partner’s mental state in my head so I could see his viewpoint better.

This has not been my experience at all. There are moments when I feel the need to practice active listening, but those moments are not the same moments as when we’re writing code. They’re thinking moments, when we discuss what we’re doing.

They also don’t feel awkward or stressful to me. Partly, I think that this sort of interaction is something I’m good at and which appeals to me. Partly, though, I suspect it’s the type of people I work with. Pivotal only hires people who are great at making close personal connections with each other. That’s why we pair with people for a day during the interview process: we mostly want to see how quickly they can become comfortable with their pair. I feel at home working with every Pivot in the office (as far as I’ve experienced). It doesn’t feel like a meeting with a client, it feels like hanging out with a friend. But then, working with clients at Pivotal usually feels the same way.

Will says that pairing failed for him because he’s an introvert. I’m an introvert, and I love pairing. Introverts take comfort and restoration in being alone or with close friends, while extroverts are more energized by meeting new people and being in larger groups. If I were pairing with the same disconnected energy that Will encountered here, I’d collapse by the end of the day too. The way we fit together at Pivotal, though, I’m energized by pairing with my colleagues.

Writing good code

And if I was writing code, I found something very interesting: I don’t think in English when I write code. I think in code first, and I can translate written code to English.

I’ve found it extremely useful as a design tool to learn to think in English—that is, in the domain—rather than in code. This is what I love about Cucumber. You clarify what you mean in English, and then you translate it into code. In my experience, the design of the code and the user experience improves from developing that strong domain language.

Process

The large part of pair programming was doing things in “The Simplest Possible Way That Could Work.” In practice, this meant doing it the way that it had been done previously, with the least possible amount of change.

When I got to the point where I understood some of the framework, I saw that there were some bugs inherent in the existing design which would make the system act unpredictably in production. In other situations, the design could improved by eliminating some classes and moving some other classes to have a single responsibility.

To me, this was “refactor mercilessly” and “once and only once.” But to my partner, this was a violation of “do the simplest thing that could possibly work.”

This is just a shame; no wonder Will hated his time doing this. First of all, to be clear, the principle of “Do The Simplest Thing That Could Possibly Work” is not part of pair programming, it’s another tenet of XP and other agile practices. It also doesn’t mean what Will’s pair told him it means.

As I’ve always practiced it, DTSTTCPW means two things, because “simplest” has two meanings. First, it means to write a test and then make it pass by expending the least effort possible; this is what Will is talking about here: write the special cases and use poor design to get it done quickly. Then it means to refactor your design to give it the least complexity possible. This cycle is known as “Red, Green, Refactor“.

DTSTTCPW is not a tool to improve your velocity of development. It is a tool to improve your quality of development.

It also went against the daily switching of partners. Whatever you start when you pair has to be finished, and checked in, by the end of the day. If you’re only looking at getting the story done by the end of the day, you’re not interested in hypothetical bugs or refactoring — you don’t have time for them and they’re not budgeted for.

This, to me, is a stupid rule. If it takes you two or three days to do the story right, take the time. It’s not worth sacrificing code quality to improve…actually I’m not sure what they’re trying to improve here.

Spikes only happen at the beginning of an iteration, and this iteration was budgeted at 8 weeks

Two more strange rules. At Pivotal, we work almost exclusively in 1 week iterations. I can’t imagine doing more that 2 weeks. And only spiking at the beginning of an iteration? I’ve never heard of that.

Furthermore, I can’t fathom the motivation behind the rule that you have to deliver your code by the end of the day if you’re not going to give it to the customer for another two months.

There is no ownership in pair programming. You’re working on a different piece every day, with a different partner. Everyone owns all the code equally. No-one really has responsibility for a single piece of it. Pair programming views this as a strength.

True, I view it as a strength myself. I enjoy not having single responsibility for any piece of code. I like knowing that any of my teammates can cover for me at any time, and that I can do the same in return. There is also joy for me in a Buddhist-like non-attachment to the code. I am not my code, and I don’t take changes to code I wrote (or co-wrote) personally. That means I don’t defend stupid choices for the sake of my ego.

Conclusion

There’s really one rule that comes out of all of this:

Hire great people who work well together.

That’s really the secret to any endeavor. Get a group of the best who work well in a particular way. That might be pairing, it might be daily code review, heck, it might be Waterfall. Polarize the team. Make sure you’re all pointing in the same direction—whatever that direction is. Everything else is dogma.