DEV Community

Cover image for The Reasons Why People Do Mob and Pair Programming Even Though It's Less Effective Than Working Alone
Florian Polster
Florian Polster

Posted on • Edited on

The Reasons Why People Do Mob and Pair Programming Even Though It's Less Effective Than Working Alone

Explaining how mob programming works is not within the scope of this article. You can find that out elsewhere. 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 (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 ... in case you want to check it out.

Top comments (1)

Collapse
 
sebbdk profile image
Sebastian Vargr • Edited

I use mob programming frequently and for one reason mainly.

Architecture / tool-building.

If we are making a new tool that everyone is gonna use, then everyone needs to be part of designing it so they understand how it works.

Afterwards we use that knowledge so people not working on it can document it while it’s being made, feedback the design decisions early on, etc.

This is especially meaningful for the many juniors we have, they get to be part of designing something complicated and they get to question the design, which they learn more from.

Finally, since the design is crowdsolved we dodge the problem of single developer tunnel vision, and as a senior I can sit back a bit without having to worry about someone going off on a tangent.

We usually only mob the system/tool skeleton, but it’s so much worth it.