Pair Programming vs. Mob Programming

Added to Technology

I was talking to some friends at Agile2016 about which they thought was more effective, pair programming done well or mob programming done well, but we ended up deciding that the jury is still out on this question, at least for the time being.

In terms of learning and spreading knowledge across a team we felt that both pairing and mobbing were comparable, with mobbing a bit more efficient. The same, we felt, is true for the quality of code produced, with both paring and mobbing yielding significantly higher code quality than software developed by a programmer working alone.

But in terms of productivity we weren’t sure which was better. We thought it probably depends upon the team and the type of problem they’re solving.

Pair ProgrammingI find that pairing done well can be much more productive than having developers work by themselves. We’re far less likely to make mistakes and introduce bugs into code when we work in pairs.

Debugging is still the number one time sink in developing software so if we can reduce the time required by debugging by writing fewer bugs, it can greatly boost the amount of features we can deliver.

I have personally not had enough experience with mob programming to get a sense of how productive a team can be when they’re working with the same problem at the same time but I do have a lot of experience with pair programming and I am always surprised at how much more productive we can be together than just working on our own.

One might think that mob programming is highly inefficient because the whole team is working on the same story at the same time but it turns out there are a lot of parallel tasks that can be worked on by different team members as a story is being implemented. The result is that most everyone is engaged most of the time when mobbing. Here is a time lapse video of a team mobbing for a day condensed into five minutes from MobProgramming.org:

In my experience, as soon as you have people start to work together they spend much more time focused on solving problems and much less time doing other things. Pair programming boosts productivity on any team—as long as they learn how to do it well.

Writing software can be a personal activity so learning how to build software collaboratively and out of a conversation rather than out of our heads can be a different skill set for some developers, but the benefits can be enormous. Pairing and mobbing are the fastest ways I know to propagate knowledge across a team, improve quality, and reinforce new habits.

I have heard a lot of people’s opinion about pairing and mobbing who have never tried either and I know from my own experiences that actually doing pairing is very different than I thought it would be like. So what about your experiences? Have you successfully done pairing or mobbing? Did you feel the team’s productivity increased or decreased?

About the Author


David Bernstein has coached and trained more than 10,000 professional software developers from several Fortune 500 companies in the course of his 30-year career. His book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software (http://BeyondLegacyCode.com), covers core technical practices for developing software.

A longtime special consultant to IBM, David trained software engineers around the world, giving them the skills to write the next generation of applications and operating systems. He is the creator of a wholesale bank-accounting software program that has become the de facto standard across the globe, as well as econometric software used to invest trillions of dollars. Over the past two decades, David has coached and trained thousands of developers at Microsoft, Yahoo, Vanguard, and dozens of other companies in Agile development practices.

David is the founder of To Be Agile, a Registered Education Provider for the Scrum Alliance, and trains Certified Scrum Developers in Scrum and XP development practices. To see a list of public classes offered by To Be Agile, go to http://ToBeAgile.com/training.

You can contact David Bernstein directly by visiting his website, http://ToBeAgile.com. David’s blog can be found at http://ToBeAgile.com/blog. You can follow David on Twitter under his account @ToBeAgile (http://www.twitter.com/ToBeAgile).


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.

Agile2023 Registration

Stay Up-to-Date!

Get updates on Agile events, programs, and more by subscribing to the Agile Alliance Newsletter.

Agile MiniCon Basics

Recent Posts

BYOC Member Lean Coffee