Mob Programming – The Good, the Bad and the Great | Hacker News Reader

Mob Programming – The Good, the Bad and the Great

underthehood.meltwater.com

312 pointstraxmaxx93 comments

Upvoting because it's a fascinating idea.

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.

Off the top of my head though, I'd be worried about:

- 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…

- 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

- 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.

- 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.

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.

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. "

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.

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.

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"

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.

This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this.

I'm glad it seems to be working for them, and I'd be willing to give this a try for a week, but I'm not even sure if I'd wait 'til I had a job lined up before giving my two week notice.

If I have to spend eight+ hours a day doing nothing but talking to people, I'm going to have no energy left for anything else. If I were single and childless, I could maybe manage this for a month, but with a wife and child, the amount of stress would be insurmountable.

My first thoughts exactly. I'd be very surprised if there were not at least one introvert on that team (there's an awful lot of us!) and would love to get their perspective.

Introversion isn't always obvious. I'm guessing in that situation, I'd seem perfectly fine during the day while I'm there, but totally unable to sleep when I got home because of all the talking swirling in my head.

Weird, when I'm in that sort of situation all day, I usually feel like doing nothing but going straight to sleep.

Oh god, seriously. I can't even stand to see my family or best friends that frequently and for that long, let alone a mob of coworkers (and I love my coworkers). I can see the value of doing this occasionally. But I couldn't spend a significant amount of time in the mob.

Totally agree.

I switched to working remote full-time just because of people who wanted to talk with me all the time in the office.

>>This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this.

Wow! That sounds more like social anxiety disorder than introversion.

http://www.webmd.com/anxiety-panic/guide/mental-health-socia...

I'm an agile coach and my clients won't stop talking about this.

Here's the deal, some 70%+ of developers are introverts. Mobbing can be great for fixing a bug or mentoring more than one person at a time but mobbing is not how you should expect your devs to work all day every day. This is probably not lost on fellow HN'ers but OMG the cargo culting amongst managers. Do not let them see this article.

Lastly, watch this time lapse video of a team mobbing and pay attention to the body language. Who is plugged in, who is checked out, who is talking the most? I think this says it all. https://youtu.be/p_pvslS4gEI

When studies show pair programming is less efficient than individual programming for senior developers, and a wash for intermediate developers, I have to assume this is a crutch for a room full of junior/poorly-skilled developers who are helping each other get work done.

Put me with a junior developer to just "pair program" and I'll be doing all the work. I've done this before as a training exercise; I think in about 12-16 sessions, each from 2 to 4 hours, the person I was paired with made one suggestion. And I still wasn't 100% efficient because I stopped a lot to explain what I was doing.

Put me in a mob programming environment with junior developers and it will be spectator programming, or I'll be wasting time "navigating" for a junior developer and cutting my productivity by 80%. I can't help but think that even teaching could be done better than that. (For reference, the person I paired with above insisted that it was extremely helpful and educational, even though it seemed hard for me to believe.)

Can you cite the studies of which you are referring? I had not heard that the efficacy of pair programming is correlated with member seniority prior to this comment.

Sorry, last time I looked for references I couldn't find them. But I did read of at least one study to that effect. To me it seems like proving the sky was blue, though.

Remember, to be efficient, pair programming has to produce more correct code than two developers would have done programming individually. Mob programming would need to produce 5x the correct output of 5 developers. It just seems insanely unlikely that me and another developer pairing could be more than 2x as efficient as me on my own. I just don't miss that many things or get stuck almost ever.

People come to me for design advice, so I don't think having someone there to work with me on the design side would be useful either; I don't spend a lot of time flailing, I just write out really solid code, really quickly. Aside from that: I am fully in support of design meetings to sketch out architecture.

Today in ~6 hours of programming so far I would have saved about 4 minutes tracking down something that I typed wrong and that broke the tests that a second developer might (probably would) have caught. But another senior developer could have written code for 6 hours as well if they hadn't been watching over my shoulder. If we're talking about senior developers, how can you not assume they'd be able to create more code with a keyboard and no interruptions?

It really just doesn't make sense that experienced developers could possibly be more efficient if only one person is typing. Junior developers? Sure, at least that's a reasonable assumption. They have so little idea what they're doing, putting two inexperienced brains together on the problem might mean they produce more than twice as much, because they collectively know enough to work far more efficiently together.

But for experienced senior level developers? I think the burden of proof is on the advocates of pair programming. Extraordinary claims and all.

The main exception is when you have two distinct subject matter experts working together on a problem. Even then I like to have two keyboards, so it's not strictly pair programming, but collaborative/synchronized programming, with expected frequent questions and back-and-forth. I did that once recently when connecting a C/C++ low latency video and audio streaming library to Unity3d and C#; I worked with a Unity expert and while he wired up the Unity side I wired up the C++ side. I laid out what the Unity part needed to look like, and he told me how Unity interfaces to DLLs on Windows. We frequently bounced ideas back and forth but were working on different parts of the code. Worked great; had the integration working in a couple hours, plus or minus.

Ah. I understand what you were saying now.

It does seem to make sense that pairing senior engineers together would not benefit a team as much as pairing a senior with juniors.

> to be efficient, pair programming has to produce more correct code... how can you not assume they'd be able to create more code with a keyboard and no interruptions

I measure efficiency by less code not more

>I measure efficiency by less code not more

Really? So if I produce no code at all or just delete code, I'm being the most efficient, even if the goal is to add new features?

If you're going to pick on semantics, you shouldn't do it with a statement that's blatantly false on the face of it.

By "correct code" I mean code that is:

* Properly designed, refactored if necessary

* DRY

* Robust

You can't add features to "correct code" while strictly removing line count. No one is just counting lines of code here; your point is specious.

Oh, good lord, that looks awful. I'd be fidgeting around like the guy in the black shirt all day.

The worst thing is it would just be exhausting. Having to constantly deal with people for eight hours straight, with no peace and quiet or private space to think would be maddening. I'd rather swing a chainsaw bucking up firewood on a hot day.

(Author here) To be fair, we are very rarely mobbing eight hours a day. Some of us come in earlier, some leave later, and you are always free to step out of the mob and go sit for yourself (even though we have been a bit bad actually doing that). I would say that we are effectively mobbing perhaps five hours each day, and the rest is spent thinking on your own, reading up on stuff, doing your own code experiments (bringing good results back into the mob) and doing all the other stuff you need to do in a day.

Wow - that. looks. exhausting. And like an overall pretty ineffective use of engineer's time. At least for the kind of SW development that I generally do.

I can imagine certain limited scenarios where this kind of problem solving approach might be useful, but on a day-to-day basis? Nope. No way.

Thanks for a balanced perspective.

The fact that someone made a website mobprogramming.org is perhaps the biggest factor that indicts this idea as a silly fad.

Hi guys, one of the authors here. Wow, the interest was a lot higher than we expected

Since you all have been asking, here's a negative excerpt from an earlier version of this post, which unfortunately got cut before the final draft. I'm starting to feel like we should write a follow up post now, but in the mean time, here's this:

"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.

My take on the introvert/extrovert thing:

I'm definitely one of the extroverts on the team (even though I, like introverts, get completely exhausted by too much interaction). I thrive in a communicative environment. We have a pretty fair mix of people on the team, and we've spent some time trying to find the balance of that, leaving room for people to leave the mob when needed etc. We usually do not mob for eight hours a day - reality hits, someone comes in early, someone likes to work late, we attend meetings, we are all parents and sometimes have to work from home, and we try to encourage each other to leave the mob at times. My guess is that we mob approximately 70% of the time. My impression is that our introverts, while finding it tiresome, are a lot more expressive and take up more social space in the group than before. The extroverts have worked hard on stepping back and leaving space. We still have ways to go, but we're getting there.

We are just one team in an organization of many teams working on different parts and features of the same system. We do not feel that we need to understand 100% of everything all the time, but our general knowledge has most definitely improved, and rapidly so. We all feel more comfortable around our own components than before.

"Here’s the crux of it, typing isn’t the bottleneck in software development"

This isn't a good argument for mob programming imo. This argument pretends as if the only reason programmers would ever work individually (or in pairs) is because more keys can be mashed in less time.

In reality, we work individually (or in pairs) so that work can be completed asynchronously. I can fix a UI defect while Jim fixes a performance issue, and Sue adds a new feature being requested by a potential client.

Having worked on a large team, and being an introvert - mob programming would have been a disaster. We had one or two extroverted personalities on the team, and they would have driven the entire effort while the majority sat and watched.

It's really cool that this works for someone. Great teams adapt and find a process that works. However, I would advise leadership at any company doing mob programming to carefully observe the more introverted personalities on the team. They probably won't say anything, but they might be dusting off their resume.

It's not about sync vs async. It's about performance. People who take up pomodoro-type work tracking are surprised at how hard it is sometimes to get 25 minutes of work done.

I know many people who perform their best when they are training somebody in a system, or are recording training, or doing a webinar. Pair programming evokes the same improvements, and it lasts.

When you're being watched you're more present, and you perform better. I would say that pair programming, assuming no huge personality friction, is more than twice as effective as single programming. There are some companies that only do pair programming, most likely because of this realisation.

You're making arguments for pair programming which is different than mob programming. Pair programming is fine. I did it for two years. Like everything in software, there are tradeoffs, but I had no major complaints.

> Work never stopped.

It shouldn't stop anyway. This way just seems like work got a lot more inefficient.

> Knowledge sharing increased

Sure... But I imagine it's hard to keep track of it all.

> The overhead got removed.

And a lot more overhead just got added.

> Anyone could go to any meeting.

Where is the win? Meetings should be targeted problem solving sessions anyway.

> Our tooling improved. When working together like this every minute is precious, and laborious manual procedures that you just buckle down and get done as an individual can no longer be tolerated.

I can see this being useful.

> Individual weaknesses could be overcome.

And individual strengths could disappear.

> Interpersonal issues and friction had to be resolved.

For me it just seems like they would grow and destroy the team.

> Stress levels dropped.

As an introvert I can't imagine a more stressful environment.

> We became more daring and forward.

A fear is that you resist change more and you become less forward.

> We became friends.

I don't think I would in an environment like this. But anyway, what relevance does becoming friends have with being productive and running a successful business? It's super good not to hate each other but everyone being friends might even be counterproductive.

Why oh why did you list 10 positive things but didn't even bother listing the negative aspects? I dunno like this completely destroying your productivity or it being a completely horrible working environment for introverts?

Meta comment: I really hate it when people quote multiple individual sentences and respond to each one separately (usually with a single sentence of their own). It sounds flippant and juvenile.

Interesting, I haven't thought about it like that. It certainly wasn't my intention.

I have not had the chance yet to use mob programming on a real project. But I have used it when teaching workshops and trainings. And it worked pretty well.

The first thing I noticed is that no-one tuned out. When I organized my trainings so that participants do the exercises alone or in pairs, some would just not do them. They might have too much problems to even get started. Or, when pairing with a better developer, just let them do the work. In the mob, paid attention everybody joined the discussion. [1] Also, I think there was a better shared understanding of the examples and the solutions after the mob programming. When working in pairs, I had to monitor 5-8 pairs in parallel and give them hints and explain stuff. With the mob, I could concentrate on one screen and join the discussion all the time.

And: Others were helping me out. At one point, a participant said: "I don't want to take the driver seat, I am no programmer, just a manager". Before I could even say something, someone else from the audience said: "Come on, try it. We tell you what to write, and after 10 minutes, we'll change again anyway".

So, to recap: I really like mob programming for teaching. I think it could also work well when a team wants to learn something new, has a hard design session or wants to bring new team members up to speed. I even think it could work during day-to-day work, but I have never tried that.

[1] Maybe I was just lucky and had a great group when we were duing mob programming. But I doubt that.

This is a really good idea: for workshops.

I don't know about day-to-day or in a classroom setting though. Whenever I did pair programming in college, one of the partners would often be overpowering in terms of skills and intelligence, and would spend most of the time getting the other up to pace. Which is great, except the laggards would often pretend to understand in fear of being looked upon as stupid.

As someone who's been on both side of the dynamics, yeahh, not sure about classroom settings. I would love to attend your workshops though!

Similar experience here at our dojo.

Mob programming is great : we've had people working effectively in languages they don't know. And so we've had product guys sit with us and practically transformed them into programmers, able to fulfill their vision.

Issues get identified much faster, and design decisions are quickly discussed and tried. Because we're able to get feedback on why we're developping, it's much easier to make the right choice for the right situation.

Test code is much more relevant, and it's much more expressive, too.

> - Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged.

Honestly, we didn't run into this problem at all, maybe because it's a dojo setting. Since we're used to mobbing, people will usually be extra careful about it. When there are many people, setting up a fishbowl is a good exercise to teach people to leave more room to others. I've had deadlocks happen during pair programming, but in a mob, it's much rarer. Also faster experiment time leads to much more tries.

> - Constantly bringing people up to speed. Maybe this is actually a good thing?

Definitely a good thing. People asking question is a good predictor of hard-to-maintain code.

"dojo"?

I assume they have a kickass system for scheduling sessions and visiting instructors. I worry about their technique, though, if the spend their time programming rather than practicing martial arts... /S

I used to use the term "mob programming" to describe a phenomenon I saw at a shop where I used to work. Officially, the process was Extreme Programming, but the physical layout worked for more. There were two "islands" of workstations with five workstations each - two of the largest monitors we could get those days (24"), room for two seats, and spare chairs. Developers each had small private cubes on the outside walls for email, phone calls, and such. Coding work was done at the islands. In theory, it was "pair programming".

What happened in practice was that any number of programmers might be gathered around a workstation, from a single programmer for a straightforward bit of coding, to a half-dozen gathered around for a thorny problem or a coding/discussion session. It was extremely effective!

I worked on a team that was set up exactly like this. Like you said, it was really effective for some ad-hoc discussion about tricky problems. The knowledge sharing was fantastic and I learned a ton.

The major downside was the chaos. If you were the team expert in some domain, you usually had someone asking questions about that domain every 20 minutes. Sometimes programming takes 4 hours of uninterrupted concentration. That work was very difficult to accomplish.

A small group of us ended up bringing in laptops and separating from the group multiple (sometimes 5) days a week. We found ourselves having to choose between finishing our own work, or helping other people finish their work.

I was kind of hoping this would be about calculating loss ratios on protection rackets and coding rigged numbers games.

There's always Analytics Made Skeezy if that's what you're into (http://analyticsmadeskeezy.com/blog/)

I'm open for all kinds of new things. What are you talking about? I guess it's an investment topic? I really don't understand at all what you are talking about, but I'm curious.

mob as in gangsters.

I think this is a fantastic as a 2-3h team activity happening every couple of weeks, if there is a clear feature/bug to be taken care of. Also, great for introducing new team members or non-engineers to the codebase. Doing it full-time does sound weird though.

The one thing that is never mentioned, and that I'd like to see the difference for, is cost to the business.

Perhaps this is good for feature development, or maintenance, but, what about contracts that deal with wholly new development of a complex system? It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. Perhaps I am being disingenuous.

I do love the idea of being able to not let the numerous tedious meetings interrupt progress.

[edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]

Having spent thousands of hours pair programming I would assume that this is were mob programming is especially valuable. The decisions you make early on are the decisions that everyone on the team will have to deal with. So if you do nothing else as a team this should be it. I actually recently had a client who was lukewarm about pair programming. But they mob programmed on new laying foundation work fit new services. We pair programmed on three new services together at the same time. So much syncing had to happen afterwards that mob programming the foundation would easily have been more efficient and effective.

> It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure.

I'd disagree there, if there's a place for mob programming, it's probably here. Given every member of the team will most likely be branching features from a singular foundation, it becomes far more important for every person to have a chance to understand the core completely. This also has the side benefit of reducing friction later on by establishing basic conventions.

A former colleague of mine, one for whom I have great respect, is applying mobbing for this right now. So far, they think it's a great way to get and keep everybody on the same page.

I'm still skeptical of mob programming, although as somebody who's done a lot of pair programming I'm open to it. But the theory makes sense to me. Early on it's easy to make decisions or fall into habits that cause trouble later. Figuring out some of those initial choices strikes me as the best place to apply a lot of brainpower. Once the architecture is established, I'd expect things would be much easier to parallelize. (But I'd still keep pairing and frequent pair rotation to keep everybody in sync.)

Jesus fucking nope. This is a good approach for some problems, and it may work for this team, for now, but I doubt that this is either sustainable or scalable.

This.

I've done mob programming a lot and it always seems to break down into either a few developers working while explaining what they are doing to others or a developer just typing what other devs tell them to type.

It does work well for knowledge sharing, but that is about it, IMO.

Also, its biggest proponents (where I worked) always seamed to be the devs who didn't actually do anything and had no real desire but learn. I'm guessing it is easier to sit in the back of the mob then fake work somewhere else. Always seemed to have a meeting when there turn got close.

How big is the mob? I don't think you want to do this 20 or more programmers (the more people you have, the more formalized communication structures you typically need).

I could imagine this working with four or five people, and I'd be worth the experiment, but I don't think I'd want to do it all the time.

(Author here) The team in this post was six when we started, four now (five if you count our coach who's actually worming himself into the mob now ;) ).

I would definitely not do this with 20. Then again I really wouldn't want to work in a team of 20 no matter the method.

I've desire to want to try exactly this. No more 2-week long code reviews, where 2-3 reviewers debate (slowly) over Github about the naming of a local variable. No more drawn out A vs B problem solving. No more 2x a day sync ups. Just put all the stakeholders in a room and crank it out together.

You'd still want to do code reviews after mob/pair programming though, because:

- the whole team might not be here and needs to review the changes to catch up.

- doing the wrong thing as a mob is still doing the wrong thing, and you may need more eyes on your code to spot that (especially if everyone during the session was convinced that what was written is right)

- IMHO, even if 10 persons were involved in writing it, a later review of the code can still improve quality (because people will actually be reading the code rather than writing it, which will expose other kinds of issues)

Who reviews, if the mob consists of everyone? If I participated in developing a thing, I would have probably already made the oversight, wouldn't see an issue.

That raises an interesting idea, you split the team, the mob and non-mob, like learning vs testing data. Dedicate some fraction of the team to the mob, then rotate out members. It seems like most of the benefits are realized, if people need skills or compassion for other roles of the project expanded, they get their turn. If the team is large enough that the mob is a minority, you minimize the effect of downsides.

FWIW, I'm getting:

uBlock Origin has prevented the following page from loading:

http://underthehood.meltwater.com/blog/2016/06/01/mob-progra...

Because of the following filter

||meltwater.com^

I think if you are passionate about a methodology then you'll make it work. To truly measure the efficacy of a methodology you'll need some reasonably unbiased observers from outside the group.

@teams that have tried this,

Do you find problems with bridging background knowledge across roles?

For instance, you have programmers with 5+ years experience reading/writing code. They understand basic data-structures & design patterns through second-nature. Does this create conflict and/or dis-engagement between the programmers & the non-programmers (management, QA, etc)?

Typically, I work on teams with scarce technical employees. Most of the team are there offloading work that doesn't require the coding background.

I think the idea from mob programming and pair programming in general is that a single programmer working on a piece of code is a liability. Everyone is prone to making mistakes and taking shortcuts especially when rushing for a deadline or when tired. More people means reduced risk especially if the skill set is diverse. Though if bugs in the code aren't much of an issue (ie fixing it quickly results in no repercussions) then one person should be good enough.

I'm having a hard time seeing this as a win. Maybe I not understanding it. You say 70% of your time is spent this way. Just looking at my own coding there's just sooooooo much busy work. Add this field on that dialog, pass this variable to that other class, write that test, etc ... my point being 5% of my work is thinking about the problem an 95% is typing, testing, iterating. Maybe I'm doing it wrong?

Intriguing concept, but I find a balance of solo work and group collaboration to be the most effective method to accomplish goals. That's why our team invests in weekly or daily (if deadlines make them imperative) reviews of our successes, key updates, and distractions. This forces us to review and reflect on work, receive good feedback, and pushes each member in the right direction.

I propose that this be codified as Borg Programming.

A more amoeba like approach could also be an interesting experiment, allowing for teams to split off and regroup as problems fall into specialty areas, regrouping to handle tests, acceptance, training, etc. For a smaller team this may not be feasible, but for a larger group it could be really interesting.

HA HA! Author here.

Our team name is "The Borg"

This looks superfun, can't wait to find a team to try it with someday.

We would spend to much time arguing until it's just a one man show at work because one of us believes they know it all.

Annnnddddd you lose out on trash talk #personToMyLeftIsAJerk

While it sounds like they made this work for their team, I can't help but be reminded of the Borg..

how did they even manage to stay all awake?

No one is as dumb as all of us.

Mob programming because they don't trust the individual developers to deliver by themselves, mob programming because no one has a clue there and they hope there is wisdom in the crowd, and mob programming because they had nothing else to do.

> individuals don't deliver > no one has a clue

Welcome to Earth.

Most teams are not able to attract or retain talent, so they have to focus on maximizing and concerting effort instead.

Yes, I upvoted because you mentioned that one of the concept is the wisdom, but I for one am aware of the other concept called 'socialism': you have to be sure that each member of the team passed the entry exam, and you have to be sure that none of the team members become lazy and relies on others to lift the heavy burden, because if everyone avoids the heavy burden, then the 'socialism' collapses.

Reply on news.ycombinator.com