TL;DR: Use pair programming, pair rotation, and mobbing to help create a more cohesive team, where information is shared freely amongst the group, and one with a better view of the overall mission of the project.

I worked on a ten week contract recently with a group of excellent software engineers and one of the strategies of software development that I had the pleasure of experiencing on this gig was the incorporation of pair programming, pair rotation, and mobbing -- the result of this included an impressive amount of work being delivered in a relatively short period of time. It also led to a more cohesive team, one where information flowed freely amongst the group, and one with a better view of the overall mission.

A brief summary of this project is that it was technically challenging work, where we took an existing Java-based monolithic web application and transformed it into an application following a microservices architecture and running in Kubernetes on AWS.

I have encountered pair programming in the past. In 2001 I worked on a project where we chose to follow this technique for developing software and we had an excellent return on investment. Sadly, this rarely shows up on projects I've worked on since then. While I've seen variations of mobbing or mob programming, pair rotation was new.

A byproduct of working in this manner includes no code ownership, no problem ownership, and there's no single person left struggling with a problem for long periods of time, nor are there gaps in understanding of what or why something was done a certain way, nor was there a need to perform a knowledge transfer exercise at the end of the project because everyone was working on the same thing at the same time.

This way of working is likely to have its detractors [#5, #6, and #7]. Already I can predict that the rebuttal being that if two people are working on the same problem that means that there are two brains doing one thing when they could be doing two -- sure they could but it'll take longer than if two people focus on one thing and then blow through it and start on the next task. Also there are two people who can explain why something was done a certain way, and that's important because people forget, people leave projects, etc. If a single task has one rotation you'll end up with three people who understand what was done.

One may also assume that switching developers halfway into a problem would slow the whole operation down as well but in my experience this is not the case at all. Firstly we would only rotate one of a two person team off of a task at any one time, and secondly it only took a few minutes for people to get acclimated with where the task was at that point and then start contributing to the solution. Finally, this strategy kept things interesting, allowing developers to work on areas of the application which they may not have had a chance to do if they were focused only on one area of the application for long periods of time, and this strategy also helped to prevent burnout.

As an aside, we didn't pair for the entire day -- in some cases we would break off and work on something individually and then bring that finding or subtask back to the task at hand and incorporate the result.

Finally, mobbing really helped to push through particularly difficult pain points and at one point we had five people working towards getting a task resolved. This was an excellent approach as the problem we had required an understanding of a certain framework and we had an expert available on the team. We had the symptoms already identified, we voiced the observations during our daily standup meeting, and when this happened we were able, as a group which now included yet another engineer, to get this problem resolved in under three hours. Compare this with working on this issue in an insular manner or with only a short burst of assistance here and there and it could have easily taken two weeks to get past this issue alone and the task itself was technically challenging.

All in all this experience was positive and I often left work at the end of the day feeling exhausted but also consistently productive, and that's very important since one is not far from burning out when they're going home day after day feeling exclusively exhausted.

So have you tried pair programming, pair rotation, and mobbing on any of the projects you've worked on? If so, I'd be interested to hear if your experience reflects what I've written in this article, so please include some comments below. I'd be especially interested in hearing where this hasn't worked, or any problem encountered when introducing this style of working.

Addendum

I had the pleasure of chatting with Benjamin Smith, a member of CTO Lunches, a few days ago and here's what Ben had to say about pair programming:

I've been pairing full time in most of my gigs for the past 10 years...

Pairing encourages doing the right thing. Most teams see this come out in higher quality code, but it applies to anything. Are you more likely to write that test first when you're by yourself or when your peer is sitting next to you? If testing is difficult for you, you might skip writing the test first or skip writing tests altogether if you are soloing. How about talking to the stakeholders to get a better understanding of what needs to be built rather than just making assumptions and carrying on? Or spending the time to figure out the performance implications of a SQL query rather than just shipping it as is.

Full time pairing removes your ego. When I'm soloing I occasionally (maybe often) get stumped by simple problems. They're problems that I know I should be able to solve, and I know the solution is going to be face-palm stupid. I will spin my wheels for 15 minutes, then 30, and feel embarrassed when I have to ask for help after 45 minutes. My Ego is what's making me feel embarrassed, and keeping me from asking for help the second I get stuck. With full time pairing, you cannot have any ego. If you get stuck or don't know something, you cannot hide it. You get used to saying "I don't know". And when your pair replies with "I don't know either", you immediately get up and find someone to help the two of you rather than waiting 45 minutes. (as a side note: I don't believe that teams that pair part time, or pair-when-it-makes-sense are able to get rid of the above ego problem).

When choosing whom will pair with whom on the team, all different match ups are productive. For example you may think that it is always a good idea to keep a junior team member paired with a senior team member, but that's not actually the case. It is equally good to have two junior people pair up and work their way through hard problems on their own.

Pairing when neither person knows tech stack can be tough. For example: if the codebase is in React, and neither have ever done any React, then you spend your time going through tutorials, and reading documentation. Reading through large amounts of text while pairing is hard since everyone reads at a different speed.

Those are a few nuggets that immediately come to mind."

References

1. Pair Programming Considered Extremely Beneficial
2. A Recipe For Successful Pair Programming
3. The Pair Programming Skeptic
4. Neha Batra - Pivotal Labs Pair Programming
5. Where Pair Programming Fails for Me
6. Why I Don't Like Pair Programming (and Why I Left Pivotal)
7. Why I love solo programming (and why I hated working for Pivotal)
8. 2x4 Pair Programming Rotation (YouTube video)
9. Mob Programming - An Experiment
10. Pair Programming – “Leave Your Ego at the Door”
11. Does Pair Programming Work?