In the early stage of starting a project you need to set up the structure of the application you are going to build. The architecture, and rough outline of where what needs to go.

By using mob programming we've been able to get an entire team ready to go at full speed in no time. Everyone knew the thought behind every decision made, and everyone had enough knowledge of the structure to hit the ground running.

That is way better than having the lead dev or architect do that work on his own and then having to spend time to explain it all to the rest of the team.

Mob programming has its advantages, but I wouldn't want to use it too often.

The main difference is walking out of the room with a pull-request setting up the structure in code instead of walking out the room with a photo made of a whiteboard.

Maybe it works for small projects or teams of mostly junior developers. But for anything remotely complex I can say from experience the architecture won't be ready in a few meetings but rather after much hammock time.

That architecture will then become a main factor in your productivity, maintainability and performance. These 3 are very, very hard to optimize for once the architecture is in place.

Other than for code reviews or mentoring junior developers, I've never seen pair/mob programming works with quality results. Its nearly impossible to solve complex problems when outside the zone, and its nearly impossible to get in the zone in a pair/mob setting.

Pair (and mob) programming makes a lot more sense when you think of it primarily as a mechanism to transfer skills and information about the project.

It's highly inefficient to have new joiners on a project getting stuck constantly. Pairing (or mobbing, if there's more than one new joiner) makes sense at least for the first two weeks.