The Power of Pair Programming, Pair Rotation, and Mob Programming: Agile Software Development on Steroids

Benefits of eXtreme Programming, Pair Programming, Mob Programming, and Pair Rotation

A byproduct of incorporating Pair Programming, Mob Programming, and Pair Rotation into a software development effort is that software engineers do not have code ownership, 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.

eXtreme Programming, Pair Programming, Mob Programming, and Pair Rotation Is Not For Everyone

Incorporating eXtreme Programming concepts such as Pair Programming, Mob Programming, and Pair Rotation into a software development effort has its detractors [#5, #6, and #7]. The rebuttal to this way of working tends to be 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 executing a pair rotation halfway through a problem would slow the whole effort down as a new software engineer arrives on the scene and has to educate themselves regarding what problem or feature is being worked on, where it’s at in the development process and what needs to be the next step. In my experience, pair rotations do not cause this change in velocity. Firstly we would only rotate one of a two-person team off of a task at any one time, and secondly, it usually 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, mob programming 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.

eXtreme Programming / Pair Programming Conversation with Ben Smith

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.”

eXtreme Programming, Pair Programming, Mob Programming, and Pair Rotation Conclusion

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 problems encountered when introducing this style of working.

Agile Software Development and eXtreme Programming 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)
   
   (the URL is no longer available: mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-and.html)
   
   
7. Why I love solo programming (and why I hated working for Pivotal)
   
   (the URL is no longer available: mwilden.blogspot.com/2010/12/why-i-love-solo-programming-and-why-i.html)
   
   
8. 2×4 Pair Programming Rotation (YouTube video)
9. Mob Programming — An Experiment
10. Pair Programming — “Leave Your Ego at the Door”
11. Does Pair Programming Work?
12. Extreme programming