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.<p>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.<p>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.
(Looks at HN) Hey! Another Agile story. Mob programming is cool. Wonder what the commenters think?<p>(Looks at comments) Sigh.<p>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 <i>anything</i> posted on HN.<p>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.<p>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.<p>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.<p>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)
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.
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 <i>that</i> weak? I work <i>best</i> alone during long, focused sessions, not hanging out with my mates.
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.
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!!!
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.<p>I'd very much prefer a methodology that focuses on knowledge sharing, respectful culture and hard knowledge (and fun).
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.
obligatory link to alternative for anyone interested: <a href="http://programming-motherfucker.com/" rel="nofollow">http://programming-motherfucker.com/</a>