18 ms·

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 wou

by SCdF 10y ago

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.

lucasnemeth 10y ago
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...
- retbull 10y ago
  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.
  - obeka 10y ago
    (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.
    - dwc 10y ago
      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.
      - icefox 10y ago
        Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.
        yoz-y 10y ago
        From the photos it does look like they did just that.
        retbull 10y ago
        that souInd s Hatlikee tthahtat a good idea.
      - obeka 10y ago
DanielBMarkham 10y ago
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.
- SCdF 10y ago
  > 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 :-/
  - DanielBMarkham 10y ago
kabes 10y ago
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.
- SCdF 10y ago
  Oh yeah good point. If you're worried about pair programming not paying off mob programming is an even more expensive proposition.
  - MaulingMonkey 10y ago
    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...
- Zebra_003 10y ago
  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.
  - yoz-y 10y ago
    > 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.
chris_st 10y ago
> 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.
- lucasnemeth 10y ago
  Biggest charismatic personality still wins. You're optimizing too much for extroverts.
  - moridinamael 10y ago
    Maybe. Probably. But if the charismatic leader leads the team to five explicit, obvious fuckups in a row, they might learn to shut their mouth for a while.
  - deleted 10y ago
    [deleted]
sean2 10y ago
<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.
Zebra_003 10y ago
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.
dcosson 10y ago
> 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.

by SCdF 10y ago

lucasnemeth 10y ago

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

retbull 10y ago
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.
- obeka 10y ago
  (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.
  - dwc 10y ago
    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.
    - icefox 10y ago
      Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.
      - yoz-y 10y ago
        From the photos it does look like they did just that.
      - retbull 10y ago
        that souInd s Hatlikee tthahtat a good idea.
    - obeka 10y ago

DanielBMarkham 10y ago

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.

SCdF 10y ago
> 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 :-/
- DanielBMarkham 10y ago

kabes 10y ago

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.

SCdF 10y ago
Oh yeah good point. If you're worried about pair programming not paying off mob programming is an even more expensive proposition.
- MaulingMonkey 10y ago
  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...
Zebra_003 10y ago
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.
- yoz-y 10y ago
  > 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.

chris_st 10y ago

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

lucasnemeth 10y ago
Biggest charismatic personality still wins. You're optimizing too much for extroverts.
- moridinamael 10y ago
  Maybe. Probably. But if the charismatic leader leads the team to five explicit, obvious fuckups in a row, they might learn to shut their mouth for a while.
- deleted 10y ago
  [deleted]

sean2 10y ago

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

Zebra_003 10y ago

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.

dcosson 10y ago

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