Hey! One of the authors here. I will do my best to provide some responses, but it's kind of late here.

- I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them.

Not at all the case, we had some bad but felt the post was kind of long so they ended up edit out. No one but us reviewed the post first ;) Actually didn't even really notice all the negatives were gone until it was mentioned...

Here is the negatives we edited: " It was not all positive. Finding a smooth way of working took a long time, and we lost team members along the way, presumably at least partly because they did not enjoy this. Personality differences became painfully obvious, and a lot of time was spent talking openly and honestly to each other on how to stop rubbing each other the wrong way.

Taking on new people is both easier and harder in this setting. The bonus is that they will come up to speed with the work a lot sooner. The drawback is that you have to redo the personality resolution dance before work will run smoothly again. "

- No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets done first). Similarly…

This was actually a focus of a retrospective today, and we do see this happening sometimes. We agreed today to try to be more aware of it, and for people to speak up when they feel it is happening.

- Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged. Especially when it comes to engineering / structural decisions, if that person thinks they know whats best you're not going to have the chance to try something (and maybe fail) and grow as a developer

This was only the case for the first few weeks, then as we point out in the article: "Interpersonal issues and friction had to be resolved. When interpersonal issues happened they get brought up much more quickly. In a ”normal team” when there are these types of interpersonal issues they are often allowed to fester. People who have issues only need to deal with each other for limited periods of time, so they just grin and bear it. This isn’t really possible inside of the mob because you would go completely insane."

So this ended up being actually the opposite effect in the long term, dominant personalities were addressed and we all grew as a result.

- No personal space. You know, maybe it's because I work from home, but sometimes my fiancee messages me a video of a cat being cute, and I might just take 2 minutes off working to watch it, because I'm a human being and not a sack of watery meat sacrificed to the gestalt. I could imagine it would be very awkward to do anything at work that wasn't explicitly working, which sounds pretty suffocating to me.

This is indeed something we struggle with, and we bring it up a lot. People are allowed to leave the mob as often as they choose, but sometimes it feels like there is a social pressure to stay. All I can say is we try to be aware of it, and one of our working agreements is to "remind each other it's OK to leave the mob"

- Constantly bringing people up to speed. Maybe this is actually a good thing? IDK, but I think if some people are faster than others, or people wander off to make a coffee or whatever, or come in at different times, or leave at different times, you may spend a lot of time going over the same decisions and working through the same problem spaces over and over again. This could be a good thing, or it could be OK that some people know about component X and some know about component Y and there is little overlap.

Not sure I follow this one :P

- If anyone from Meltwater is reading this I'd be interested to know if you had any problems (these ones or other), because it sounds like-- ignoring the first month-- this plan has no flaws. Which seems hard to believe.

It's definitely not been all smiles and roses, and we have struggles like any team, but we also all agree that this has been an amazing experience and well worth any negative effects we've seen.

Hey Zebra, thanks for the replies, IMO you should edit your blog post (or link to your comment here) because that's a really helpful set of counter experiences that make your blog post feel much more genuine, compelling and relatable.

>> Constantly bringing people up to speed… > Not sure I follow this one :P

The point came from (as did all of them really) past experiences of mine. I've found it can be incredibly painful and time-consuming to expect 100% of people to understand 100% of situations. A few years and companies ago we got to the point where there was an entire day of planning for a 2 week sprint, due to this requirement for total understanding. It was not an enjoyable experience, and I still don't believe it was a worthwhile tradeoff.

I believe everyone should understand the whole project at a high level. However, I'm very comfortable with only understanding a portion of the software or features being currently developed at the deep level required to work on them at that instant. I'm happy to let go and trust that the people who do understand will do a good job without my input. I can always learn about it later if I have to, because while I don't have to know about everything, I also don't just know about anything (ie never completely silo).

But: I'm willing to accept that this is my impatience at play, and that everything would be better off if everyone understood everything. It's just been historically (for me) been a very large price to pay.

obeka is going to post the negatives in the comments.

I think the main point about "Constantly bringing people up to speed" is that this now happens without overhead, just sort of naturally, to the point that we don't even notice it.

I believe another reason to not pointing out the flaws come from mob thinking. It becomes very hard to criticize "the collective".

And yes, I think you have a great point on Biggest personality wins, that is already a problem on meetings. Lot's of amazing developers I've worked with had a hard time speaking in meetings...

I agree that the personalities have to be all fairly extroverted for both mob and pair programming. However, as a counterpoint to it becoming hard to criticize "the collective" I've experienced that at least with pair programming the opposite trends to happen. No one had a sense of personal code ownership, so no one gets too attached to a particular implementation or feels personally criticized when criticizing code. My expectation would be that that would happen even less when mob programming. I wonder though what would happen if you had multiple mobs that never rotate team members. I could see that that might quickly escalate to a us vs them situation.

I wonder if you could set up a round robin programming order. Something like switching which is typing every day. So like whole team puts input while one person types, then delegate one person to drive the discussion. I don't know if that would help much though or just put it back into pair programming with extra overhead.

(Author here) We do round robin for keyboard input, but a lot more often than that. We try to switch a couple of times each hour.

We do not have a particular person driving the discussion though, I do not see that that would help us in any particular way.

In my limited experience pair programming it usually went like, "How about if we combined these and frobbed before...aww, let me drive and I'll show you." Who had the keyboard might stay the same for hours, or might switch every 15 minutes, depending.

The person typing should not be driving. It's a bit hard to get to that point and we fail it a lot of times, but as a general rule the person sitting at the keyboard tries not to drive.

Also, if you are not the person currently at the keyboard, you are not allowed to just take over. We used strict time boxes at first to make sure that this didn't happen, these days we are a bit more relaxed since it isn't really an issue anymore.

Yeah, well, we did a lot of things our own way. We tried some things. Some of them stuck, some of them we adapted to suit us, and other things we dropped.

> The person typing should not be driving.

What's the reasoning behind this? My guess is that it's to prevent pair programming from turning into lone programming with an observer. If that's the case it wasn't a problem for our specific situation. No matter who had the keyboard, there was collaboration. Why separate the keyboard from the person who can fastest/best get the code on screen for consideration?

> Also, if you are not the person currently at the keyboard, you are not allowed to just take over. We used strict time boxes at first to make sure that this didn't happen

Why? Of course you shouldn't snatch the keyboard out of someone's hands, but such behavior should be addressed in other ways than by making rules. I suspect it's not that, but something else. Even so, I have to wonder if it's a social issue that would still be better addressed in other ways than by imposing rigid structure.

Anyway, switching when we wanted did not seem to pose any problems. If we missed out on some benefits then I'd like to know about them.

Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.

From the photos it does look like they did just that.

that souInd s Hatlikee tthahtat a good idea.

I've participated once or twice and watched mob programming a bunch of times. Here's some feedback, for what it's worth.

- Thinking aloud lets you solve problems in parallel, rather than sequentially. But if you're still hung up on something, you're free to be quiet and think, or think later

- If it's an ego fight, you've lost no matter how you code. Better to get it out in the open and deal with it. (And perhaps let the person go)

- I think personal space/time depends on the team, as it should. I have the opposite problem: I get bored and drift off online. I find other people in the room help me get back on track

- Nope. Actually that's the beauty of mob programming. Everybody is up to speed all of the time. It eliminates bringing people up to speed.

I think there are edge cases, one of which is bad teams, ie, bad mixes of people. But mob programming doesn't cause that. It might point it out a lot quicker, though. There are other edge cases, but the industry is still working through those.

The problem that mob programming solves is one that a heckuva lot of programmers don't even know exists: over-specialization in technology development.

> If it's an ego fight, you've lost no matter how you code. Better to get it out in the open and deal with it. (And perhaps let the person go)

I know what you mean, but "you've lost" is a bit too final for me. Obviously ideally you would never have these people, but in reality you may do, and as that's not the only quality you're judging them on letting them go might be a little harsh.

What I'm talking about is the idea of maybe a quiet developer trying something a little different, and having that good dna making it into the code-base. If you have a group of people who nearly all believe that mocking is a good idea, but someone would like to try refactoring so you don't even _need_ mocking, then I'd worry that in mob programming you'd never have that attempted.

Or perhaps everyone would be really open to that and because everyone is in a group more of those ideas would surface, and more different ideas and approaches would make it into the codebase.

I honestly don't know which of those two situations would occur, and maybe it's up to the team. I'd be really worried about the former, though maybe that says more about my background, who I am and the teams I've worked in though :-/

I exaggerated to make a point. Of course you'd work with folks. Apologies for the hyperbole.

You have a good point, but consider this: the team is in the hook for whatever the code is anyway, whether there are disagreements or not. So the real question is whether or not you surface those disagreements (or bury them, in your example), or simply don't address them at all.

I'm thinking you surface them, even if the herd mentality moves in the wrong direction. Unfortunately, unless you can deliver the entire thing on your own, social skills count as much as technical skills. The bigger the team and the more people think "that's not my job", the more the team norming becomes more important than the implementation details.

Or -- to continue with the hyperbole -- if you get it wrong, and you all get it wrong? You did your best. If you do a great job and the team flops? The guy paying the bill isn't going to be so happy with "Yeah, but if they had only listened to me...." Your job is to make the team/project succeed, not be the best coder.

Mobbing is still in the hype cycle. I remain wary, but cautiously enthusiastic. It'll probably be another 2-3 years before all the warts come out.

Hey no worries, your perspective (as a breathing human who's actually done this before, whereas I'm very much being a couch referee or whatever that phrase is) is really interesting.

I think it's a cool idea. I'd still worry about people taking over, coasting, checking out or otherwise not getting to express themselves, but realistically that's a constant concern anyway, regardless of whichever development structure you take.

But I'd try it. I'd be exhausted, frustrated and very much in need of a drink after the first day, but that says more about me than it does the approach :-)

So the really cool question is this: if mobbing can bring a room full of BAs, testers, biz folks, and designers up to speed on the technical details of implementation (which it can), how far does that go? Could you take, say, two really good developers and five smart and enthusiastic people from the street and end up with a good team?

Beats me. But I really want to try :)

<quote>I might just take 2 minutes off working to watch it</quote>

People say mob programming is great for keeping programmers on task, but just as frequently the reverse is true.

I've done a lot of accidental mob programing recently, and frequently, someone wants to take a break and show you this awesome video, they get enough support that lead typist goes to check it out, and suddenly you don't have just one off task programmer, mindlessly browsing YouTube, you have 5!

Until someone works up the courage to party-poop and demands that the team get back on task.

> Biggest personality wins.

I'd argue that a "big enough" personality (thinking of some past cow-orkers here) cause disruption and difficulty no matter what the situation.

Right now we're hiring people with personality type as the foremost criteria. One difficult person is really too many for a small team.

Biggest charismatic personality still wins. You're optimizing too much for extroverts.

And maybe the cost? If you pay 5 developers, I wonder how much more (or less) they get done by working individually or by doing this mob programming.

Hey! One of the authors here.

I really wish we had hard data on this. But we did not have reliable metrics in place before. I would however argue that there isn't data the other way either ;)

But in lack of hard data, I can say what our gut feeling is. We started with mob programming because we felt we had a total inability to deliver anything (lots of half done work), and now we feel like we are delivery frequently with high quality.

> we felt we had a total inability to deliver anything (lots of half done work)

While I can sympathise with this, I do believe that this is mainly a problem with management. In order for a group to be productive there needs to be a single mind calling the big shots, in your case you offloaded this responsibility to a mob, usually this is the job of a product lead/project manager.

Oh yeah good point. If you're worried about pair programming not paying off mob programming is an even more expensive proposition.

I suspect that it's the kind of thing that pays off... sometimes.

There are times when the machine is the bottleneck. Multiple monitors, SSDs, many cores, multiple machines... and I still end up waiting for (re)builds because I touched a header on each machine, trying to tackle a problem.

Having a whole mob blocked on those recompiles is going to be hideously wasteful.

On the other hand, there are times when I've "mob programmed" without knowing the term. The typical pattern was someone would loudly "WTF?", that'd pique the interest of a nearby programmer, and then a 3rd would be roped in via questions, as we knew they'd taken over the relevant mess of code... often oscillating between all eyes on the same bit of code, and spinning off to launch our own investigations into related bits...

> No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets done first). Similarly…

I could imagine maybe this one could go either way, depending on the loudest personality type. Every team has a range of skill levels and styles, so there are inevitably people who skew towards more time writing code and less time thinking (as well as the opposite. Some middle ground is probably optimal).

A lot of these people might just never have really thought about and might not know any other way, and if the majority and/or loudest voice of the mob is more conservative about thinking through things before starting to code, it'll rub off on everyone else.

That said I do agree with your sentiment to some extent, I find I personally do better thinking on my own than in a group. Part of it is needing to go off in a ton of different directions and then consolidate the ideas afterwards, and in a group setting there's a pressure to talk through things aloud which dramatically slows this ability to branch out.