Embrace the experiment

Everybody’s favourite Ruby-on-Rails creator, David Heinemeier Hansson tweets:

Everyone should try pair programming, but if it’s not for you, you’re not broken or retrograde. Maybe you just like the one-on-one conversation with the computer to be the default.

and:

Pair programming is a beautiful practice, and I respect those who can do it day-in, day-out. But I would not want to be a programmer if I had to do it all the time. I need not merely long stretches of uninterrupted time, but outright solitude to flourish.

One of the replies to this tweet from Domantas Jackuñas is worth mentioning:

The point is that it takes time. You have to embrace the experiment in order to drive through the dip of the change curve. Sure it won’t work in every context as it requires appropriate environment, but it’s important to collect data and run it long enough to get the real outcome.

This reminds me very much of my early experiences of pair programming.

The first time I tried it, the team I was in was half-hearted in our attitude. We didn’t exactly expect it to fail, but neither did we put in the effort to try to make it work. We didn’t spend much time trying it, didn’t try to work through any of the challenges, and didn’t spend much time discussing it. In the end, it just fizzled out and we went back to isolated individual contributions.

The second time I tried it, I joined a different team that was already practicing a full suite of Extreme Programming practices, of which pair programming is just one. We paired on all production code and all infrastructure tasks (including, in those days, trudging off to Telehouse data centre in London to do some pair-cable-crimping).

My immediate reaction to this was very similar to that of DHH’s. ‘This just isn’t for me,’ I thought. After 6 hours of pairing every day, I went home exhausted and frazzled.

But because the team had already developed healthy pairing practices, I was encouraged and helped along the way. Over the course of a few weeks, I came to accept and then enjoy pairing.

But I had to become better at it to do that. In that regard, it’s like many other skills that you need to get some master in before you start really enjoying it.

So, don’t dismiss something new just because it doesn’t chime with you or your team immediately. Very few truly positive things come along like this.

If you’re thinking of running a pair-programming experiment in a team that has not done it before, make sure that you plan the experiment, and that your team is willing to commit to making the best of it. That should include anticipating the hurdles you might encounter along the way, and how you’re going to try and get over them.

After all, there is no point running an experiment if you’re collectively disinterested in really finding out whether there is a benefit to be had.

Tell me, what’s been you experiences of pair-programming in the past?

All the best,

– Jim