Blog index

Pair Programming Presentation at FutureLearn

James and I recently gave a presentation about pair programming to the development team at FutureLearn. I thought I’d document how it came about, how we approached it and what we learnt from it.

The presentation (source and pdf) is available on GitHub although I’d question how much sense it makes without commentary.

Background

Both James and I enjoy pairing and regularly advocate its use in the teams we work with. FutureLearn was no exception, and we often found ourselves pushing for more of it. While the general consensus appeared to be that people enjoyed it and wanted to do more of it, we still felt that it wasn’t happening as much as it might.

After some discussion with Joel, we agreed to give a presentation to the team about pairing. Our hope was that sharing our understanding of it would help the team come up with their own ideas and ultimately make it easier to decide when to, and when not to, pair.

Preparation

We knew we wanted to present something but we weren’t entirely clear on exactly what it would be. We started out trying a couple of different approaches. I spent some time writing notes about various aspects of pairing: What I enjoyed, what I found hard and so on. James started thinking about a potential survey that we could send to people to gauge how best to target our presentation. We decided against the survey, although we took aspects of it, and focused on combining our efforts to come up with an overview of our experiences of pairing.

Having struggled to make much progress, James took it away and started sketching out some slides using a simple Markdown document and Deckset to preview. He also brought in some of the history of pairing from the Extreme Programming Explained book at this point. I hadn’t considered this angle when we first started talking about the presentation but found it really useful as a reminder of the history of a number of practices that I find myself using most days.

With the presentation date getting closer, we came together to pull everything we had into a coherent structure. I found pairing on this really useful: It certainly avoided me from going off on tangents or procrastinating as much as I might otherwise have done on such an unfamiliar task. Sitting next to each other in a quiet room also gave us the opportunity to read it aloud as we wrote, giving us an idea of how we might deliver the presentation as we went. In addition, I think writing the presentation together meant that it ended up with a consistent sounding voice, rather than one of us coming through more than the other.

While I was happy with what we ended up with, I was also surprised by how long it took to prepare. There was still more that we wanted to include, including an important section about people skills, but we simply ran out of time. Hopefully we’ll make some amendments if/when we give the talk again.

The presentation

The talk we ended up with was split into the following main topics.

What it is and what it isn’t

We pulled quotes from the XP Explained book to describe pair programming as envisaged by Kent Beck.

Why we think it’s important

We discuss pair programming and how it’s a central component of XP: It supports and is supported by many of the other practices. If a development team is using some of the other XP practices (as many do) but not pair programming then they’re not getting the full benefits.

Why we think it’s a Good Thing™

We explain how we think pair programming results in a number of desirable qualities for both the team (e.g. efficiency) and the codebase (e.g. simplicity).

Why we sometimes find it hard to start

We list a number of situations that can make it hard for us to start pairing. We address each of them with some suggestions that might make it easier to start in future.

Why we sometimes find it hard to do

We list a number of reasons that can make the process of pairing quite painful. We address each of them with some suggestions that might ease some of this pain in future.

The delivery

We only ran through the presentation in full once before delivering it to the team. It took around 25 minutes although we imagined it taking longer in front of an audience. I think it took around 30/35 minutes in the end, which we were both pretty happy with. Hopefully it didn’t feel too long for those watching!

Neither of us are natural presenters but I think our delivery was OK. We started out reading our slide notes almost verbatim but slowly got into it and became a bit more fluid in our delivery.

We finished up with around 15 to 20 minutes of questions and answers. I think (and hope) we did an OK job of answering people.

Conclusion

I really enjoyed the process of creating and delivering this talk and I really hope it was useful for the team. Pairing on the presentation really helped me and reminded me that pairing can absolutely be useful and effective on non development tasks.

Preparing for it reminded me that pair programming has a fairly well defined definition and is a skill that needs to be learnt and practised. I think it’s quite common for developers to be expected to be able to pair without any real explanation of what it means or how to do it. Hopefully I’ll be more aware of this in future and get better at pairing with people that might not have done it quite so much.

If we were to create another presentation then I think I’d want us to come together to start pairing on it earlier. I’m still really surprised by quite how long it took us to create.