“Pair programming is a software development technique in which two programmers work together at one keyboard” – Wikipedia, April 2009.

While this is basically true, I’d say it is a flavor of pair programming. If you’ve never heard about it before, this definition gives you a basic idea of what pair programming is about. Or if you’ve never tried it, this approach is one easy way to start. Just sit down next to your peer and start working. The only modification to your working area you need to do is to move your chair closer to your colleagues. And off you go!

First contact

I was involved in a project, with a few other colleagues, which we felt wasn’t heading in the right direction. We had pretty much lost contact with the customer and that us and the customer to feel pretty desperate. We needed to make some dramatic changes to the way we worked. That was obvious.

This was late 2000, ‘eXtreme Programming’ was rather new and one colleague had just picked up the ‘White Book’ as we came to call it. Namely Kent Becks – ‘eXtreme Programming Explained’.

For the first time we came in contact with a methodology that seemed to suit our needs. Light weight, focused on programming practices and pretty much the same values we had within our company. Despite the warnings that came with the book. ‘Don’t try this to save a project’ etc. We decided to give it a go. We also decided if we’re going to try XP we’re going to try all of XP.

Like entering a pool, cannonball style, we would try it all at once. Since Pair programming is one of the practices described in the book this became my first contact with it. Little did I know how much it would affect my programming, collaboration and people skills.

Fumbling and Stumbling

Since we were all beginners I believe that helped us a lot. I think it contributed to a higher tolerance to each others flaws, because we knew we were all beginners. No one had tried pair programming as described in the White book before. Sure, we had sat down together to tackle a difficult problem or to explain something we just did. But none of us had programmed with another developer, side by side, over an extended period of time. How was this going to feel?

Practicalities  at first

One of the earliest memories I have of difficulties during pair programming came from practicalities. How and when to switch partners, who where supposed to team up initially and what happens when someone gets sick or isn’t at the office.

Switching pairs

Switching gave us some headache at first. We never managed to switch pairs mid-iteration. The fact that two pairs very seldom finished a chunk of work at the same time made us wonder. Should one pair wait for the other while doing nothing. Or pick a less important piece of work that was of substantially smaller size, than the most important, just to let the others catch up? We decided not to switch in the midst of an iteration.

It didn’t feel optimal but it was way much better than not switching at all.

Teaming up

We had one rule that I think helped a lot. It was particularly helpful when teaming up. We were not allowed to say no when someone asked for help. This made me a lot more courageous. I clearly remember one time when I was hesitant to pick a piece of work. Then I remembered the rule, grabbed a very interesting story and asked a more seasoned developer for help. He joined me of course, and we both learned a lot. I learned more about programming that he did. And he learned about himself, about his teaching techniques and a few new ways to look at problems.

Now, new challenges arose. Some preferred working together and started teaming up very often.

Sick, sick, sick

When someone got sick or wasn’t at the office for any other reason funny things happened. Some of us took that as an excuse for not pairing while others saw a chance to switch partners. I enjoyed pairing so much so I would rather sit with another pair, than alone. Making us a triple. This wasn’t optimal but neither was sitting alone, I thought.

I found out that there was always someone that was more keen on sitting alone than me. So I normally ended up pairing and they normally ended up sitting alone. Another challenge.

Splash …

All had jumped in the water and it made a big splash. It wasn’t freezing as some of us expected. It wasn’t very hard to swim in a new way either. It was actually rather pleasant for most of us …

About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

2 responses »

  1. Christian says:

    For me it took several years before I actually got it. In the beginning I knew that pair programming was a good thing, but it kept me from producing code fast enough. At least that was what I thought. Being all stressed up by deadlines I didn’t realize how much faster pair programming is in the long run!

    Today however, I feel very lonely and left out in the cold without a partner to discuss all those micro decisions with.

  2. Ola Ellnestam says:

    I’ve found that many believe that it’s very counter intuitive. In terms of productivity.

    I feel lonely too without a pairing partner. I wonder if that means we’re pair-infected? 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s