11 ms·

The Benefits of 'Mob Programming'

29 points by danielbryantuk 11y ago

colund 11y ago
Just one of those buzzwords. Programming in crowds may work for some and not for others. A few years ago I was learning about agile and various methodologies. Eventually, I realized that most people writing most about the various trends and ideas did so to mainly to make a buck. I'd very much prefer a methodology that focuses on knowledge sharing, respectful culture and hard knowledge (and fun).
- wpietri 11y ago
  Knowing a lot of the early Agile people, I'd say your bit about "most people writing most about the various trends and ideas did so to mainly to make a buck" is both helpfully true and dangerously false. There are definitely some people who say, "Oh, X is fashionable, so I'll jump in and become a thinkfluencer." Those people are dangerous. There aren't many, though; call 'em 10% or so. There are plenty more people who jump in to participate but just don't understand the ideas very well. They're not really out to make a buck. They're mostly trying to help people; it's just that they have a poor understanding of how little they know. These people often do very well because their clients also don't know much, and really don't want to know much. This is the bulk of the market, say 75%. But then there are 15% of people who are sincere, very smart, and deep thinkers. This is often a hindrance in making a buck. Their ideas are so radical (in both senses of the word) that a lot of their potential audience gets scared off. However, they are definitely worth listening to. Their solutions may not match your circumstances, so you shouldn't follow them blindly. But for me they're the ones most likely to trigger deep reevaluation of something I thought I understood. My take is that the Extreme Programming community is mostly in that latter camp. If you're really looking for an approach with the values that you state, I'd encourage you to check them out. The original books, 15+ years old at this point, are a bit out of date, but still useful as foundation. The community itself has mostly moved on to different practices, but Josh Kerievsky gives a good summary of where it has gotten to: https://www.industriallogic.com/blog/modern-agile/ https://www.industriallogic.com/blog/modern-agile/
jahewson 11y ago
This seems like a great way to increase the cost of getting work done by a factor of five. Not to mention getting and end result which is a "design by committee". Brainstorming features this way could certainly be useful, but programming - seriously, are the individual team members that weak? I work best alone during long, focused sessions, not hanging out with my mates.
- wpietri 11y ago
  This is also basically the standard critique of pair programming, but I've never heard it come from somebody who has done much pair programming. I've never tried mob programming myself, but I've done a ton of pairing, so I wouldn't be averse to trying this on occasion. The hard thing about making software is not the typing, it's the thinking. And on teams, some of that thinking can be individual, but a lot of it has to be collaborative if the software is to end up having any real coherence. As Kent Beck writes, "division of labor is a dangerous fiction when all of your big problems are integration problems". I've done a lot of good work alone in long, focused sessions. But I've done even better work in long, focused sessions together. Hands down the best code bases I've worked on are the ones where we did it all using pair programming while changing pairs every half-day or so.
  - danielbryantuk 11y ago
    +1 to the comment here. I see lots of discussions after code has been cut ('why this design?', 'why this library?', 'did you consider this?'), which would have been much more valuable to have as the code is being written. With mobbing I'm thinking you can answer these questions and discuss opinions at the most appropriate time in the software creation lifecycle...
    - slavik81 11y ago
      I found it incredibly stressful to try to answer those questions before I finished. Pair programming meant I could never try anything new, because I couldn't answer those questions immediately.
dasmoth 11y ago
This is parody -- right?
landmark2 11y ago
obligatory link to alternative for anyone interested: http://programming-motherfucker.com/ http://programming-motherfucker.com/
ctstover 11y ago
If you consider that the entire point of Agile™ is evidently to reduce programmer efficiency by 40-60% over the "actually give them a few days in a row of uninterrupted time to work" technique, this makes sense. By letting 7 simultaneous cooks in the kitchen not for meal planning, but for actually cooking the same dish, the near optimum 3% of employee value can realized.
- wpietri 11y ago
  I agree, but I'd like to separate here Agile from Agile™. I was at a number of the early Agile conferences, and the biggest critique at the time, a valid one, was it was mainly a revolt of programmers saying, "Enough of this management bullshit, let's create a method where work actually gets done." That's why one of the points in the agile manifesto [1] is about valuing working software. It was an amazing group of people. But what has become Agile™ is, in my view, the same managerial power structures co-opting the vocabulary and the energy for change into something so watered down that it has a lot of the same problems. [2] This works for many organizations because their actual priorities are less about getting things done or delivering customer value, and more about maintaining primate status hierarchies and letting people play out their office dramas. So for those people who are at the rare organizations that would like to get something done, I encourage them to dig past the pile of Agile™ horseshit to find the perfectly serviceable horses. [1] http://agilemanifesto.org/ http://agilemanifesto.org/ [2] I've written more about this here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
  - nickbauman 11y ago
    I agree. The local chapter of the Project Management Institute has 7,000 members. I don't think there are 7,000 people here in town who can actually write code, so this is where Agile becomes Agile™. They map agile buzzwords into their own screwed up processes designed mostly to appear important and CYA. It's almost the definition of an anathema.
- JustSomeNobody 11y ago
  What I love is when agile is followed so rigidly that it simply isn't agile at all.
overgard 11y ago
Oh god, this reminds me of a company I left where management would regularly talk about "swarming" a problem. They'd form these temporary "feature teams", where they'd assign more programmers than were needed to a problem, while other important concerns were left abandoned. From a management optics standpoint, it let them tell the executives "Look how serious we are about this feature!" From a practical standpoint it was pretty much a disaster. You would end up with one person actually qualified to do the work being dragged in five directions by trying to manage five other people who were well meaning, but had no idea what to do. It ended up with one or two people being stressed out and overworked, and the rest of the team being mostly idle. I know this isn't exactly the same thing, and I try to keep an open mind on these things, but you could just as easily call this "programming by committee". We all know how great anything described by "X by committee" turns out. There's nothing wrong with gathering a few people together to work on a thorny problem, but that sort of gathering has to happen organically. When people trying to sell management books turn this sort of thing into a buzzword, it just ends up being cluelessly applied by some starry eyed junior manager that has found a shiny new hammer and the world looks like nails to him.
- JustSomeNobody 11y ago
  Sounds to me like they tried to apply "put out fires" management style to new features. Sadly, most managers are of the wait until there's a fire type. These are not really managers except in title as they simply are not managing anything.
  - overgard 11y ago
    Yep, that's a pretty apt description. The sad thing is almost all these fires were avoidable if they had let forward thinking engineers work on problems we all knew were upcoming, but weren't the emergency of the week. Unfortunately, the dedication to "agile" seemed to mean that anything outside the scope of the next two weeks pretty much didn't exist, and if you tried to do anything that wasn't in the "backlog" you were some sort of rogue cowboy. (Even if the backlog was empty!) Fundamentally, the problem was trust -- the management didn't trust the engineers, so they micromanaged them poorly while invoking "agile" to make heavy management somehow seem like a populist movement for the "team". And because the team was micromanaged and not trusted, motivation was low and the output was poor, which just made the problems worse. (Not surprisingly: the company recently just laid off the entire staff)
mbfg 11y ago
God bless the designated typer in the mob. That is a job worse than death.
- wpietri 11y ago
  I imagine it depends a lot on the mob. I've definitely been in living rooms where people were basically doing mob video game playing. If the mob is enthusiastic, respectful, and generally helpful, it can be a lot of fun.
  - dasmoth 11y ago
    The video-game-playing mobs occur, pretty much by definition, organically. If this stuff catches on, it will be imposed from above on coders who are far from enthusiastic.
    - wpietri 11y ago
      There are quite a number of good software development practices that are mostly great when teams choose them on their own but often produce terrible results when imposed. Unit tests and writing documentation are two that come to mind. I think the problem isn't with the individual practices, it's with a theory of management that treats programmers as minions rather than professionals. And, of course, with programmers' widespread acquiescence to that power relationship.
DanielBMarkham 11y ago
(Looks at HN) Hey! Another Agile story. Mob programming is cool. Wonder what the commenters think? (Looks at comments) Sigh. Okay, everybody who has actually mob programmed? Raise your hands. Let's hear how it went. Everybody who has an opinion -- usually about how it's all a crock of shit and a waste of time -- you guys to the back of the room. No offense, but this is kinda the standard response to anything posted on HN. Modern programming, especially at BigCorp, is much more about tooling and environment (both technical and social) than it is technology. People who get together and work a piece of value from front to back in the system quickly gain a common understanding of how all that tooling and environmental structure is supposed to work. In a day or two of mobbing, you can take a team through what might otherwise be months of mentoring and code reviews. It's so effective at teaching "how to make solutions here" that I'm hearing stories of noobs picking up an entire language simply by participating in a mobbing group over a few weeks. Got a team that wants to make mob programming into another committee meeting? Guess what? Your team is broken. Get that problem out in the open on day one and then fix it. Don't hide behind process. Mobbing makes you do this. If programming were measured by the amount of keys you pressed, or KLOC, mob programming would make no sense at all. But it's not. Programming is about making computers do things that people want, whether it's one line of code or a million. So what you're optimizing for is the appropriate mix of diverse problem-solving methodologies and personality types in order to maximize the quality of creative responses to the business problem. I'm a big mobbing fan -- having watched it and done it. I don't think it's a magic bullet or appropriate everywhere. I think the interesting part of this discussion will be identifying situations where it's a bad idea. (And of course that would be done empirically, not anecdotally)
- jacalata 11y ago
  So do you think mobbing is something that you would do instead of pair programming, or do you see them as complementary?
  - DanielBMarkham 11y ago
    From what I've seen so far (10-15 examples), mobbing is superior to pair programming. Pair programming has a lot of social pressure (I don't like working with X!) that just isn't there with mob programming. There's gotta be some inflection points, though. This is an extremely interesting area to watch. If it holds up in general, it's really completely re-structuring what we think about when we think about a tech team delivering value. ADD: The thing to keep in mind here is that we're still very early in the hype cycle. Lots of smoke, and people who make money waving their arms around. Having said that, there is real value here. So it's interesting.
corysama 11y ago
More info: http://www.infoq.com/interviews/zuill-mob-programming http://www.infoq.com/interviews/zuill-mob-programming https://vimeo.com/131643015 https://vimeo.com/131643015
dmcg 11y ago
I've been pair-programming for over 15 years now, and was introduced to mobbing by Woody and Llewellyn a couple of years ago. I've tried it in a couple of teams for specific tasks. I don't think that in a team of experienced devs I would mob all the time (although if the team wanted to I wouldn't veto it), but it definitely has its place. In particular for learning new techniques, large refactorings and exploring solutions with customers.
msie 11y ago
Sigh, some trends in this industry have me regretting choosing programming as a profession. I like programming alone godammit! Will programming alone be relegated to hobby projects while I head to the meeting room for all my job-related programming duties? Bah humbug!!!
eikenberry 11y ago
The only benefit of mob programming in my experience is for training. Working through a program together can teach people new techniques and details about libraries/frameworks. Other than that it is worthless.

Just one of those buzzwords. Programming in crowds may work for some and not for others. A few years ago I was learning about agile and various methodologies. Eventually, I realized that most people writing most about the various trends and ideas did so to mainly to make a buck. I'd very much prefer a methodology that focuses on knowledge sharing, respectful culture and hard knowledge (and fun).

wpietri 11y ago
Knowing a lot of the early Agile people, I'd say your bit about "most people writing most about the various trends and ideas did so to mainly to make a buck" is both helpfully true and dangerously false. There are definitely some people who say, "Oh, X is fashionable, so I'll jump in and become a thinkfluencer." Those people are dangerous. There aren't many, though; call 'em 10% or so. There are plenty more people who jump in to participate but just don't understand the ideas very well. They're not really out to make a buck. They're mostly trying to help people; it's just that they have a poor understanding of how little they know. These people often do very well because their clients also don't know much, and really don't want to know much. This is the bulk of the market, say 75%. But then there are 15% of people who are sincere, very smart, and deep thinkers. This is often a hindrance in making a buck. Their ideas are so radical (in both senses of the word) that a lot of their potential audience gets scared off. However, they are definitely worth listening to. Their solutions may not match your circumstances, so you shouldn't follow them blindly. But for me they're the ones most likely to trigger deep reevaluation of something I thought I understood. My take is that the Extreme Programming community is mostly in that latter camp. If you're really looking for an approach with the values that you state, I'd encourage you to check them out. The original books, 15+ years old at this point, are a bit out of date, but still useful as foundation. The community itself has mostly moved on to different practices, but Josh Kerievsky gives a good summary of where it has gotten to: https://www.industriallogic.com/blog/modern-agile/ https://www.industriallogic.com/blog/modern-agile/

jahewson 11y ago

This seems like a great way to increase the cost of getting work done by a factor of five. Not to mention getting and end result which is a "design by committee". Brainstorming features this way could certainly be useful, but programming - seriously, are the individual team members that weak? I work best alone during long, focused sessions, not hanging out with my mates.

wpietri 11y ago
This is also basically the standard critique of pair programming, but I've never heard it come from somebody who has done much pair programming. I've never tried mob programming myself, but I've done a ton of pairing, so I wouldn't be averse to trying this on occasion. The hard thing about making software is not the typing, it's the thinking. And on teams, some of that thinking can be individual, but a lot of it has to be collaborative if the software is to end up having any real coherence. As Kent Beck writes, "division of labor is a dangerous fiction when all of your big problems are integration problems". I've done a lot of good work alone in long, focused sessions. But I've done even better work in long, focused sessions together. Hands down the best code bases I've worked on are the ones where we did it all using pair programming while changing pairs every half-day or so.
- danielbryantuk 11y ago
  +1 to the comment here. I see lots of discussions after code has been cut ('why this design?', 'why this library?', 'did you consider this?'), which would have been much more valuable to have as the code is being written. With mobbing I'm thinking you can answer these questions and discuss opinions at the most appropriate time in the software creation lifecycle...
  - slavik81 11y ago
    I found it incredibly stressful to try to answer those questions before I finished. Pair programming meant I could never try anything new, because I couldn't answer those questions immediately.

dasmoth 11y ago

This is parody -- right?

landmark2 11y ago

obligatory link to alternative for anyone interested: http://programming-motherfucker.com/ http://programming-motherfucker.com/

ctstover 11y ago

If you consider that the entire point of Agile™ is evidently to reduce programmer efficiency by 40-60% over the "actually give them a few days in a row of uninterrupted time to work" technique, this makes sense. By letting 7 simultaneous cooks in the kitchen not for meal planning, but for actually cooking the same dish, the near optimum 3% of employee value can realized.

wpietri 11y ago
I agree, but I'd like to separate here Agile from Agile™. I was at a number of the early Agile conferences, and the biggest critique at the time, a valid one, was it was mainly a revolt of programmers saying, "Enough of this management bullshit, let's create a method where work actually gets done." That's why one of the points in the agile manifesto [1] is about valuing working software. It was an amazing group of people. But what has become Agile™ is, in my view, the same managerial power structures co-opting the vocabulary and the energy for change into something so watered down that it has a lot of the same problems. [2] This works for many organizations because their actual priorities are less about getting things done or delivering customer value, and more about maintaining primate status hierarchies and letting people play out their office dramas. So for those people who are at the rare organizations that would like to get something done, I encourage them to dig past the pile of Agile™ horseshit to find the perfectly serviceable horses. [1] http://agilemanifesto.org/ http://agilemanifesto.org/ [2] I've written more about this here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
- nickbauman 11y ago
  I agree. The local chapter of the Project Management Institute has 7,000 members. I don't think there are 7,000 people here in town who can actually write code, so this is where Agile becomes Agile™. They map agile buzzwords into their own screwed up processes designed mostly to appear important and CYA. It's almost the definition of an anathema.
JustSomeNobody 11y ago
What I love is when agile is followed so rigidly that it simply isn't agile at all.

overgard 11y ago

Oh god, this reminds me of a company I left where management would regularly talk about "swarming" a problem. They'd form these temporary "feature teams", where they'd assign more programmers than were needed to a problem, while other important concerns were left abandoned. From a management optics standpoint, it let them tell the executives "Look how serious we are about this feature!" From a practical standpoint it was pretty much a disaster. You would end up with one person actually qualified to do the work being dragged in five directions by trying to manage five other people who were well meaning, but had no idea what to do. It ended up with one or two people being stressed out and overworked, and the rest of the team being mostly idle. I know this isn't exactly the same thing, and I try to keep an open mind on these things, but you could just as easily call this "programming by committee". We all know how great anything described by "X by committee" turns out. There's nothing wrong with gathering a few people together to work on a thorny problem, but that sort of gathering has to happen organically. When people trying to sell management books turn this sort of thing into a buzzword, it just ends up being cluelessly applied by some starry eyed junior manager that has found a shiny new hammer and the world looks like nails to him.

JustSomeNobody 11y ago
Sounds to me like they tried to apply "put out fires" management style to new features. Sadly, most managers are of the wait until there's a fire type. These are not really managers except in title as they simply are not managing anything.
- overgard 11y ago
  Yep, that's a pretty apt description. The sad thing is almost all these fires were avoidable if they had let forward thinking engineers work on problems we all knew were upcoming, but weren't the emergency of the week. Unfortunately, the dedication to "agile" seemed to mean that anything outside the scope of the next two weeks pretty much didn't exist, and if you tried to do anything that wasn't in the "backlog" you were some sort of rogue cowboy. (Even if the backlog was empty!) Fundamentally, the problem was trust -- the management didn't trust the engineers, so they micromanaged them poorly while invoking "agile" to make heavy management somehow seem like a populist movement for the "team". And because the team was micromanaged and not trusted, motivation was low and the output was poor, which just made the problems worse. (Not surprisingly: the company recently just laid off the entire staff)

mbfg 11y ago

God bless the designated typer in the mob. That is a job worse than death.

wpietri 11y ago
I imagine it depends a lot on the mob. I've definitely been in living rooms where people were basically doing mob video game playing. If the mob is enthusiastic, respectful, and generally helpful, it can be a lot of fun.
- dasmoth 11y ago
  The video-game-playing mobs occur, pretty much by definition, organically. If this stuff catches on, it will be imposed from above on coders who are far from enthusiastic.
  - wpietri 11y ago
    There are quite a number of good software development practices that are mostly great when teams choose them on their own but often produce terrible results when imposed. Unit tests and writing documentation are two that come to mind. I think the problem isn't with the individual practices, it's with a theory of management that treats programmers as minions rather than professionals. And, of course, with programmers' widespread acquiescence to that power relationship.

DanielBMarkham 11y ago

(Looks at HN) Hey! Another Agile story. Mob programming is cool. Wonder what the commenters think? (Looks at comments) Sigh. Okay, everybody who has actually mob programmed? Raise your hands. Let's hear how it went. Everybody who has an opinion -- usually about how it's all a crock of shit and a waste of time -- you guys to the back of the room. No offense, but this is kinda the standard response to anything posted on HN. Modern programming, especially at BigCorp, is much more about tooling and environment (both technical and social) than it is technology. People who get together and work a piece of value from front to back in the system quickly gain a common understanding of how all that tooling and environmental structure is supposed to work. In a day or two of mobbing, you can take a team through what might otherwise be months of mentoring and code reviews. It's so effective at teaching "how to make solutions here" that I'm hearing stories of noobs picking up an entire language simply by participating in a mobbing group over a few weeks. Got a team that wants to make mob programming into another committee meeting? Guess what? Your team is broken. Get that problem out in the open on day one and then fix it. Don't hide behind process. Mobbing makes you do this. If programming were measured by the amount of keys you pressed, or KLOC, mob programming would make no sense at all. But it's not. Programming is about making computers do things that people want, whether it's one line of code or a million. So what you're optimizing for is the appropriate mix of diverse problem-solving methodologies and personality types in order to maximize the quality of creative responses to the business problem. I'm a big mobbing fan -- having watched it and done it. I don't think it's a magic bullet or appropriate everywhere. I think the interesting part of this discussion will be identifying situations where it's a bad idea. (And of course that would be done empirically, not anecdotally)

jacalata 11y ago
So do you think mobbing is something that you would do instead of pair programming, or do you see them as complementary?
- DanielBMarkham 11y ago
  From what I've seen so far (10-15 examples), mobbing is superior to pair programming. Pair programming has a lot of social pressure (I don't like working with X!) that just isn't there with mob programming. There's gotta be some inflection points, though. This is an extremely interesting area to watch. If it holds up in general, it's really completely re-structuring what we think about when we think about a tech team delivering value. ADD: The thing to keep in mind here is that we're still very early in the hype cycle. Lots of smoke, and people who make money waving their arms around. Having said that, there is real value here. So it's interesting.

corysama 11y ago

More info: http://www.infoq.com/interviews/zuill-mob-programming http://www.infoq.com/interviews/zuill-mob-programming https://vimeo.com/131643015 https://vimeo.com/131643015

dmcg 11y ago

I've been pair-programming for over 15 years now, and was introduced to mobbing by Woody and Llewellyn a couple of years ago. I've tried it in a couple of teams for specific tasks. I don't think that in a team of experienced devs I would mob all the time (although if the team wanted to I wouldn't veto it), but it definitely has its place. In particular for learning new techniques, large refactorings and exploring solutions with customers.

msie 11y ago

Sigh, some trends in this industry have me regretting choosing programming as a profession. I like programming alone godammit! Will programming alone be relegated to hobby projects while I head to the meeting room for all my job-related programming duties? Bah humbug!!!

eikenberry 11y ago

The only benefit of mob programming in my experience is for training. Working through a program together can teach people new techniques and details about libraries/frameworks. Other than that it is worthless.