
The Benefits of 'Mob Programming' - danielbryantuk
http://www.infoq.com/news/2015/11/unruly-mob-programming
======
overgard
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
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
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)

~~~
danielbryantuk
I think this reply thread is confusing the specific, i.e. the technique of
'mobbing', with the general, i.e. the (mis-management) approach to fixing
issues with 'all hands to the pumps'.

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

------
DanielBMarkham
(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)

~~~
corysama
Agreed. There is a narrative programmers tell when complaining online. It goes
like

> 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/](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.

~~~
danielbryantuk
Wow! I couldn't have said it better myself. Having worked across a variety of
codebases and teams over the last 10+ years, it has become obvious to me that
delivering software is an inherently social activity (at least the delivery of
valuable software)

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

~~~
msie
People have been doing this for years, they've just not put a name to it.

~~~
danielbryantuk
In my experience working as a consultant across multiple organisations, not
_enough_ people have been doing this.

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

------
ctstover
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
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...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-
in/)

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

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

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

~~~
wpietri
Ok. Now I've heard it from one person. But I think "there's almost never the
need to have two people continuously coding together" is a pretty strong
conclusion from one person's experience. Do you mean that you haven't noticed
the value in it?

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...](http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-programming/)

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://slesinsky.org/brian/code/pair_versus_review.html](http://slesinsky.org/brian/code/pair_versus_review.html)

------
dmcg
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
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!!!

------
colund
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
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/)

------
corysama
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)

------
dasmoth
This is parody -- right?

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

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

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

------
landmark2
obligatory link to alternative for anyone interested: [http://programming-
motherfucker.com/](http://programming-motherfucker.com/)

