Some thoughts on pairing during software development! (Part 1)

Over the past few months, I’ve been pairing (pair programming) with other Software Engineers when working on stories during our sprints. It’s been fun, and the first time in a while I’ve enjoyed and felt rewarded while ‘pairing’. While I’m sitting in the sun, on a beach in Wales enjoying our holiday with my family, I look back and consider it hasn’t all been plain sailing…

My first exposure to pair programming came as I was working on a team that was writing API’s for some of our business services. It was a relatively new formed team with a range of mid to junior level Software Engineers, a Business Analyst, a Product Owner, a QA tester and a Scrum Master.

We’re sitting around a table in the office’s shared kitchen (there’s never a decent sized meeting room when you need one) for our bi-weekly retrospective. The lead Software Engineer had joined us, and we are discussing the usual ups and downs of the last sprint.

We had discovered that the current block of work we had was a set of rather similar tasks. Each developer was picking up a new story ready for development that would be a small task, but all on a similar part of the micro-service. It was found that during committing the code into source control, that software engineers were overwriting or change the same chunk of code. This meant lots of merge conflicts and code reviews taking longer.

So trying to address this issue, the team had decided in the Retrospective that developers should be teaming up with each other and working on the chunk in parallel.

“Ok let’s give pair programming a go now the team is mature enough” says the Lead Software Engineer.

Over the next few weeks and months, we attempted to introduce pair programming into the team, with some challenges. As I’ve later moved onto other teams, I’ve seen some sort of pattern to how teams adopt pair programming.

There’s some thoughts I’ve had on pairing which may help:

Pairing should not be forced. Processes, routines or schedules don’t work.

So it’s week one of our team attempting to pair programme. How should we approach this? “We have four developers on our team, so let’s rotate” one engineer suggests.

“Ok, but when do we know when to change pairs?” asks another.

After a relatively lengthy discussion, it was decided that the following ‘rules/guidelines/suggestions’ would be introduced.

• Developers should switch pairs once a story is completed.
• If a pair has been together for more than two days, they must switch.
• One developer must remain on the story from start to finish.
• Nobody should work on a story on their own.

Ok, it was a little flakey. But it offered what we thought some ground rules for pairing to take off and work… How very wrong we were!

It turns out that even though we liked the idea of pairing when it came down to it, the first few weeks were incredibly hard. We had been used to independently working on our separate tickets. When ‘forced’ to work with another human being with a separate way of working, a different way of tackling a problem or even an alternative biological clock (toilet breaks, and caffeine pitstops) it is incredibly hard.

I personally found keeping my train of thought almost impossible. With many interruptions and events during the day which would take our focus off pressing keys and coding.

It wasn’t working! Not only was it rather frustrating for the developers, but the ‘rules’ we had come up with were not working. The nature of different stories being completed at separate times meant some developers were waiting around. Waiting for another pair to finish and unable to pick up a new story to work on - We had created dependencies between stories without realising it!

We tried to adapt the rules and even printed out a schedule that hung above our Kanban board. We could see which pairs were currently together, and developers waiting for a new partner.

Eventually, due to frustration and general lack of interest, the pairing stopped, and we naturally drifted back into flying solo! Much to the Scrum Master’s disappointment. In a last ditched effort, the Scrum Master regularly walked around the office trying to find developers not pairing. ‘Strongly’ encouraging them to relocate to another developers desk and pair. Which then started to cause other pain points, like feeling Micromanaged.

Forcing pair programming doesn’t work. If anything it turns the developers against the idea and we will then try our utmost to avoid it.

Pairing works best when it is natural, encouraged but not mandatory

If you’re reading this thinking ‘how should I introduce pairing into my team’ this is my suggestion.

Don’t have any rules/suggestions/enforced ways of working… Let it be natural. Takedown the printed schedule. Delete the list of ‘rules’ you have. Certainly do not walk around the office asking why a developer is not in a pair!

Just go ahead, walk up to another developer and say something along the lines of “Is it OK if I sit with you and learn about what you’re working on?”

I’m speaking for myself, but Developers are very proud of their work (I know we shouldn’t be protective of our code, but show me a developer who isn’t proud of their work, and I’ll eat my keyboard).

Asking the above will hopefully put the other developer into a mode where they want to show you what they’ve been working on, and open the door to further conversation. Sit with them. Don’t try and take over, kindly ask them to explain what they’re doing. Why they decided to take that approach, and what their train of thought is.

Hopefully, after a while, they may feel comfortable with you being there, and you may be able to offer suggestions, praise their work or help with that question they just Googled. But remember, you are in their territory. Don’t take over, and certainly don’t say they are doing something wrong. You will just rattle their cage and will not gain their trust (Yes this is like taming a Lion).

Eventually, you should have built up that level of trust with the developer that you can ask the following question, something along the lines of “I really enjoyed working alongside you with that Story, could we possibly try to work on the next one together?” You should offer to ‘drive’ this time.

Over time, you should find it easier to work alongside each other. So you can start to build on those foundations. Offer to take turns coding, writing a test, or contacting someone to find an answer to a question. I find writing tests together is really beneficial. You can help each other to spot the pitfalls or that bit of information missing from the Story.

When you feel like you’re walking, it’s then time to run… If you’ve been sharing a computer and taking turns driving, you may want to take it up a gear and install some sort of screen sharing software (like slack, teams etc). Basically a piece of software that you can see each other’s screens and control if needed. In the remote world we now exist in (COVID-19), this is must for pairing, but back in a physical office space, it might not be always needed (remember to do whatever feels natural).

Based off experience, both members of the pair need to offer to take turns. Don’t just sit back and watch the other developer. Get involved, even if you don’t know how to write the test, refactor the method, or create that builder pattern - offer to take control and work together to achieve the goal.

I’m not saying this will lead to amazing results, or it will work for all developers, but it’s worked for me. Especially when you join a new team, or start a new piece of work. It can work with a junior or senior developer, as long as you are humble and accept it may take time to form that trust in the pairing relationship.

You’ll encounter problems, you’ll get frustrated that the other developer may not have understood you. You will get annoyed when your idea isn’t implemented as you’d have liked. This is all part of the process, and as you keep pairing, you’ll overcome these little problems.

What you’ll get is a high performing, focused pair, taking stories across the board in record time. When the story first gets picked up, it will be understood quicker, code reviews will be quicker (as the story has technically been under review the whole time as the developers discuss the implementation) and will move to ‘Done’ faster.

In part two, I’ll talk about:

• Pairing works when both engineers are not multitasking or context switching and can focus 100% of their time to the task.
• Both Engineers should start and finish the task together. Breaks in between are of course beneficial.
• Engineers can join the pair, but not replace anyone from the original pair.
• Both engineers should be given equal credit.
• Pairing remotely can seem hard, but is actually feasible and often works better than physical pairing.
• Is it just Software Engineers who can pair? No.

Link to Part 2: Further thoughts on pairing during software development!