The Reasons Why People Do Mob and Pair Programming Even Though It's Less Effective Than Working Alone
Tags: productivity, programming
Published: 2020-03-22 13:50:24

> Explaining how mob programming works is not within the scope of this article. You can find [that](https://en.wikipedia.org/wiki/Mob_programming) out [elsewhere](https://www.remotemobprogramming.org/). You might know pair programming. That's a special case of mob programming where `mob.size() == 2` so to speak.

I read an [interesting article](https://www.heise.de/hintergrund/Erfolgreich-im-Homeoffice-arbeiten-4681061.html?seite=all) (in german) yesterday and it made me realize something that I want to share with you. It's the justification of mob programming which the article got down really well IMO. The benefits weren't so clear to me before.

> TL;DR
> Yes, in terms of throughput mob programming is less efficient than working independently and you should keep that in mind. However, mob programming enables faster time-to-market for single tasks/features. It's also perfect to spread knowledge among the team and that has valuable long-term benefits.

If you've ever wondered 'why would anyone do mob programming at work, isn't it inefficient to have multiple people work on the same thing instead of everyone working in parallel?' - You're right. If every person is working on separate tasks you get more work done. That modus operandi does yield higher __throughput__ of work items.

What mob programming optimizes for is __time-to-market__ -- getting one specific task done completely in the shortest amount of time possible. Here's how:

* If one person were to work on the task alone they might come to a point where they need some information from a co-worker. Getting that question answered will introduce some latency. In mob programming that co-worker is right there and can respond immediately.
* Where one person alone might have to look something up or google something. In mob programming there might be someone able to help instantly.
* Mob programmed code is already reviewed! If people are working separately, they submit their code for review resulting in more latency especially if further changes are requested from the reviewer. We do code reviews because individuals tend to suffer from tunnel vision, forget to write tests/documentation or are too lazy to do quality refactorings. Basically the problem is that one person can only look at the problem from one angle. With mob programming all these problems disappear as multiple people provide multiple angles to look at the problem.

Another benefit is __knowledge sharing__. While working on the same problem, knowledge about that particular domain is spread across the team. The first result of this is that in the future team members become more __independent__ when working alone because less questions pop up. The second result is that everyone in the team can respond to requests from the __stakeholders__. And if any of the members go on vacation __no hand-overs__ are necessary.

The last upside is that by spending time together the __team grows together__ possibly with shared moments of accomplishment which is probably the most effective bonding activity you can do.

Curiously, if you mix in mob programming from time to time the team becomes more effective in working independently.

If you have programmed in a mob before please let me know how it went in the comments!

The authors of the article I mentioned in the beginning have made a [website](https://www.remotemobprogramming.org/) ... in case you want to check it out.