The Benefits of 'Mob Programming'
infoq.com
infoq.com
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.
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.
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)
The only thing the Unruly team is dogmatic about is delivering valuable software. The techniques they talk about are simply this - techniques.
In my work as a consultant there is rarely a 'one-size fits all' technique to developing a feature, but knowledge of several approaches is very valuable.
This is the purpose of the article - to allow you to consider the addition of 'mobbing' to your existing approaches of single development and pairing
As a teacher I never assign group projects for their own sake. If something makes more sense being done in a group, we do that. If it's better done by individuals, we work alone and share our results.
(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)
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.
This is the sticking point for many people, as we still like to draw analogies between coding and typing, or coding and physically building structures (which inherently are limited by the application of manual labour), rather than seeing it for the value-creation/design-thinking act that it actually is (and accordingly the need for good imagination and decision-making abilities)...
> If only they would just leave me alone! I would sit in silence for 4 hours pondering the depths of the system at hand. Then I would spend 30 minutes invoking VIM macros at 240 actions/minute (that's why I spent 12 years integrating VIM into my lower cortex, after all). Then I would spend 5 minutes admiring the perfection of my creation before retiring to the pub. Tomorrow, everyone will find everything just works so much better than yesterday and they won't even know how or why. I'll just lean back and say "You're Welcome."
But, the reality is that you don't work in a vacuum; you don't know the whole situation; your proposed solution probably isn't as good as you'd like to think it is; other people are doing stupid things and breaking stuff because you never mentor them; you are doing stupid things and breaking stuff because other people aren't informing you about what you should be doing better; even when you are actively working on code, you spend less than 5% of your time actually typing code; if you are a senior engineer working on non-trivial systems, you probably spend more time sorting out how other people's code works than your own.
These realities don't fit the http://hackertyper.net/ narrative. They're embarrassing and require inter-personal effort to resolve. But, brushing them off is making you a whole lot less productive than you should be.
IMHO, the reason we've seen the rise of XP, Behaviour-driven Design (BDD) and DevOps is that each part of the software delivery community is gradually coming to this conclusion within their own realm
Mobbing for me just makes sense on so many level, especially from the point of view of adding 'expertise' to a problem/solution:
Not sure on how to integrate the latest language feature into your code - bring someone with experience into the mob...
Not sure how this feature could be tested - bring a QA/tester into the mob...
Not sure of the infrastructure requirements of this new database - bring an operator into the mob...
As for a putting a name on it - a name can help spread the idea (ubiquitous language and all that), but it can lead to abuse and cargo-culting.
I believe a label is often helpful during the 'innovation' and 'early adoption' diffusion of innovation phase, and this is firmly where mobbing is at the moment
> 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!!!
So, in the middle of a lot of "Bah humbug!!!", it's good to have a reminder that maybe this awkward interpersonal stuff is important to, you know, actually getting real shit done.
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/
[2] I've written more about this here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
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.
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...
I'll add that when I'm just messing around with something, that's often solo coding time. E.g., trying out a new library just for the fun of it, or playing around with approaches to a problem. But for me that's throwaway code, so I don't need the quality boost or the shared understanding that comes from pairing
I've done a fair amount of pair programming and generally found it to be an inefficient waste of time.
Having colleagues around to bounce an idea off of is great, but there's almost never the need to have two people continuously coding together.
One possibility is that your team was maybe not so good at it. Sometimes that happens:
http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra...
Another is that you were working in a domain where the benefits of pairing don't matter so much. For me, they include improved code quality, less siloing, making it easier to bring people on to the team, faster iteration, and a greatly increased ability to actually take vacations due to improved truck factor.
On long-lived code bases with high business value and fast iteration, quality and collaborative ease become very important to me. Basically, I put pairing in the same category as code reviews, but I think it's much more efficient. And others do as well:
http://benjiweber.co.uk/blog/2015/09/02/team-efficiency-is-i...
I'd very much prefer a methodology that focuses on knowledge sharing, respectful culture and hard knowledge (and fun).
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:
If this stuff catches on, it will be imposed from above on coders who are far from enthusiastic.
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.