The fact that this worked for me, I later came to learn, was a symptom of an underlying lack of commitment in the team.
Suddenly no one wandered off into the weeds to deliberate on some inconsequential aspect of the code (this is a charitable euphemism for went off reading news sites!) The group drive to progress was greater than the individuals. As one individual's attention would wane, another would pick up the slack, keen to show they were engaged in front of their peers and that would have a self righting effect on the interest of the person who started to drift.
So for a while we plundered on, amazed by the power of our new tool. Productivity was up to where it should be, quality was excellent again, the junior dev was getting a real education too.
I started reflecting on why this was successful - I wondered if there was some insight I could reuse elsewhere. I slowly came to realise it was just a neat partial solution to an underlying much bigger problem.
Fixing the underlying engagement problem turned out to be a journey but it was good fun.
Mob programming has earned a place in my toolbox of life experience, but there's an inscription on the handle to remind me that its effectiveness could be a sign of deeper project issues.
To be clear I'm not saying this is the case for the OP's team! It was just one life experience point I thought was worth sharing.
Mob programming is the go to solutions at work. We have been using mob programming for a couple of month for specific parts of existing and new projects and it still surprises me how good it is. I never liked pair programming and when I heard of thought this was the same thing, just more wast of time. But I was wrong. You should try it out, its free you know, no $ to pay.
But as always we are people and people like different things, but with mob programming I think you have a really good chance of succeeding. Just remember to take 5 min to explain how to do it before you start.
How much of programming is actually typing code though? I think that less than 5% of my time is actually typing, the rest is thinking.
So if you go with mob programming and have one guy doing 50% typing whilst the other guys are thinking. In theory it could be just as efficient, with the added benefit that everyone understands the system and is onboard with the design. Plus the usual benefits of pair programming: you can train juniors, many eyes to catch the bugs, etc...
Sure there is a price for everything. Especially not getting everyone engaged and commited to a project. My guess is that you spend a lot of time doing code reviews, demos or just explaining how stuff works, time that you dont have to "waste" when doing mob programming.
I can imagine this being useful at particular junctures in a project - perhaps it's real crunch time on a critical feature, where everyone needs to put their minds together to solve one difficult problem, everyone is months in and on an even footing, and you just need one guy to type it all out; or perhaps a brainstorming session where you're trying to throw together a workable basic prototype very quickly; or even debugging and fixing a complex issue might be well-served by this approach - but I can only imagine doing this day-in, day-out would drive many people absolutely insane. I'm sure there are genuine reasons why many developers like to sit at their desks with their headphones on and the volume turned up (even if it does annoy the hell out of managers).
In my own team, we periodically pair up to do peer review and testing, and sometimes prototyping of new features. I try and avoid doing this more than about once a week, though.
We decided to adopt mob programming as we believed it would help establish a shared and consistent understanding of how the new frontend would be built.
Okay, now I understand. It's a way to solve the problem of very few people understanding the design. Seems an expensive solution, but the expense of your programmers not understanding the design of what they're working on can be pretty high as well, and good documentation is hard to write and sometimes hard to make people read. I don't know if it's that hard, but this would work as an alternative.
I suspect this only works when the problem being solved is pretty simple, or isn't actually a "problem" but only a question of layout and design.
I've been in a workshop with Woody Zuill, talks by Arlo Belshee, and my team has some mob programming under our belt. We don't use it exclusively, but it's a great tool to have in your toolbelt.
We have a skill-diverse team -- a tech lead, 4 web and backend developers, 2 iOS, 2 Android, and 2 QE (one of whom is moving toward a backend developer.) At any time. we may have 1-2 support tasks and a project. We have a range of junior to senior developers.
Sometimes, we have sufficiently broken-out work that we can keep everyone engaged at a single-stream, but even that's a polite fiction. The junior developers get stuck, which has them spinning their wheels for periods of time until they realize they're stuck, then bring in a more senior engineer whose work is then interrupted. Sometimes, the senior engineers get stuck in analysis paralysis where a discussion would be more productive. That jumps into an impromptu meeting which solves the problem but interrupts half the team as anyone interested hashes the problem out.
Then, there's the tech lead (me) who gets interrupted constantly to the point that it's not worth taking tasks sometimes. There's production support, cross-team support, and intra-team support. That isn't to mention the meetings. :)
And sometimes, the tasks on a project aren't parallelizable, especially at the beginning. It used to be that everyone would get into a giant room and discuss design, then break it out into tasks and go. Mob programming can replace that phase by having everyone in that room do the work to flesh out the idea.
Then there is the work to peer review a decision and test it. When a ticket is in peer review or test, that developer is in full interrupt mode. They may get work done on the next ticket, but it is historically a period of low productivity for a developer.
The fundamental hypothesis of mob programming is that the interruptions of a team combined with the overhead of process are high enough that condensing to a single workstream+ actually doesn't reduce productivity.
If a team is working on a mob, and a production support request comes in, I (or one member of the team) can peel off of the mob and figure it out. If a support ticket comes in, a member of the team can peel off and work on it, have it reviewed by another in the mob, then tested by another, and the single stream workflow is still going. It becomes easier to catch up on what has happened than return to it.
When working on hairier problems, it turns out that a distributed memory works better than holding it in one individual's head. It turns out that it can feel slower but the work happens quicker. Sticking points are resolved quicker rather than devolving into analysis paralysis.
It seems counter-intuitive that the work doesn't slow down, but the decrease in peer review and testing time (because QE has been involved from the beginning thinking about testing scenarios and how to test) that the reduction in overhead compensates for more people working on the same problem.
There are other paths to streamlining a team's efficiency, but this is an interesting one worth trying in some cases.
I think it's important to take regular breaks because pair programming or mob programming requires a very level of high energy. The code quality definitely improves because of many eyeballs into the problem and provides an instant feedback for the code written.
Have to admit, when I read 'mob programming', I expected something closer to how open source works. Or random people on social media committing code for the site in a big free for all.
I still don't get why this 'multiple people on one computer' thing would be helpful though. I mean, couldn't a team working on the same site on multiple computers do pretty much the same thing with the bonus of a quicker turn around? Seems like micromanagement gone insane...
Haven't ever really worked with a big enough team for it. I mean, current workplace has exactly two people doing web development, and the previous one had maybe between one and three people per project. If we tried to work like this, nothing would ever get done.
This explains a lot. The gov.uk site is such an unusable mess it can only have been designed by a mob.
In my view mob/pair programming is a very inefficient way to work. I guess it depends on the people, but personally I think much more clearly alone than in a group setting. Have many eyes on code is great and I'm all for peer review, but a mob making decisions is a recipe for group think and the less dominant personalities (and probably best coders) being ignored.
"the less dominant personalities (and probably best coders) being ignored"
WAT
How are you going to get your skills recognized by your teammates, if you avoid working with them?
Of course you're being ignored by them: you're ignoring them the rest of the time!
In my experience, in a context of technical arguments, great speakers with doubtful technical skills don't last very long against shy highly-skilled techies pointing out relevant weaknesses in the proposed solution, and asking tough questions.
The bullshitters win, never forget that. Reality doesn't have any bearing, when they are parroting the words of what those with real power want to hear.
Suddenly no one wandered off into the weeds to deliberate on some inconsequential aspect of the code (this is a charitable euphemism for went off reading news sites!) The group drive to progress was greater than the individuals. As one individual's attention would wane, another would pick up the slack, keen to show they were engaged in front of their peers and that would have a self righting effect on the interest of the person who started to drift.
So for a while we plundered on, amazed by the power of our new tool. Productivity was up to where it should be, quality was excellent again, the junior dev was getting a real education too.
I started reflecting on why this was successful - I wondered if there was some insight I could reuse elsewhere. I slowly came to realise it was just a neat partial solution to an underlying much bigger problem.
Fixing the underlying engagement problem turned out to be a journey but it was good fun.
Mob programming has earned a place in my toolbox of life experience, but there's an inscription on the handle to remind me that its effectiveness could be a sign of deeper project issues.
To be clear I'm not saying this is the case for the OP's team! It was just one life experience point I thought was worth sharing.