
Mob Programming – The Good, the Bad and the Great - traxmaxx
http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/
======
SCdF
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
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
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
(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
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
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
From the photos it does look like they did just that.

------
pavel_lishin
This is an introvert's nightmare. I feel like going to a room and turning off
all the lights just reading about this.

I'm glad it seems to be working for them, and I'd be willing to give this a
try for a week, but I'm not even sure if I'd wait 'til I had a job lined up
before giving my two week notice.

If I have to spend eight+ hours a day doing nothing but talking to people, I'm
going to have no energy left for anything else. If I were single and
childless, I could maybe manage this for a month, but with a wife and child,
the amount of stress would be insurmountable.

~~~
emilong
My first thoughts exactly. I'd be very surprised if there were not at least
one introvert on that team (there's an awful lot of us!) and would love to get
their perspective.

Introversion isn't always obvious. I'm guessing in that situation, I'd seem
perfectly fine during the day while I'm there, but totally unable to sleep
when I got home because of all the talking swirling in my head.

~~~
pavel_lishin
Weird, when I'm in that sort of situation all day, I usually feel like doing
nothing but going straight to sleep.

------
ryanmarsh
I'm an agile coach and my clients won't stop talking about this.

Here's the deal, some 70%+ of developers are introverts. Mobbing can be great
for fixing a bug or mentoring more than one person at a time but mobbing is
not how you should expect your devs to work all day every day. This is
probably not lost on fellow HN'ers but OMG the cargo culting amongst managers.
Do not let them see this article.

Lastly, watch this time lapse video of a team mobbing and pay attention to the
body language. Who is plugged in, who is checked out, who is talking the most?
I think this says it all.
[https://youtu.be/p_pvslS4gEI](https://youtu.be/p_pvslS4gEI)

~~~
SomeCallMeTim
When studies show pair programming is less efficient than individual
programming for senior developers, and a wash for intermediate developers, I
have to assume this is a crutch for a room full of junior/poorly-skilled
developers who are helping each other get work done.

Put me with a junior developer to just "pair program" and I'll be doing all
the work. I've done this before as a training exercise; I think in about 12-16
sessions, each from 2 to 4 hours, the person I was paired with made one
suggestion. And I still wasn't 100% efficient because I stopped a lot to
explain what I was doing.

Put me in a mob programming environment with junior developers and it will be
spectator programming, or I'll be wasting time "navigating" for a junior
developer and cutting my productivity by 80%. I can't help but think that even
teaching could be done better than that. (For reference, the person I paired
with above insisted that it was extremely helpful and educational, even though
it seemed hard for me to believe.)

~~~
jstx
Can you cite the studies of which you are referring? I had not heard that the
efficacy of pair programming is correlated with member seniority prior to this
comment.

~~~
SomeCallMeTim
Sorry, last time I looked for references I couldn't find them. But I did read
of at least one study to that effect. To me it seems like proving the sky was
blue, though.

Remember, to be efficient, pair programming has to produce more correct code
than two developers would have done programming individually. Mob programming
would need to produce 5x the correct output of 5 developers. It just seems
insanely unlikely that me and another developer pairing could be more than 2x
as efficient as me on my own. I just don't miss that many things or get stuck
almost ever.

People come to _me_ for design advice, so I don't think having someone there
to work with me on the design side would be useful either; I don't spend a lot
of time flailing, I just write out really solid code, really quickly. Aside
from that: I am fully in support of design meetings to sketch out
architecture.

Today in ~6 hours of programming so far I would have saved about 4 minutes
tracking down something that I typed wrong and that broke the tests that a
second developer might (probably would) have caught. But another senior
developer could have written code for 6 hours as well if they hadn't been
watching over my shoulder. If we're talking about senior developers, how can
you _not_ assume they'd be able to create more code with a keyboard and no
interruptions?

It really just _doesn 't make sense_ that experienced developers could
possibly be more efficient if only one person is typing. Junior developers?
Sure, at least that's a reasonable assumption. They have so little idea what
they're doing, putting two inexperienced brains together on the problem might
mean they produce more than twice as much, because they collectively know
enough to work far more efficiently together.

But for experienced senior level developers? I think the burden of proof is on
the advocates of pair programming. Extraordinary claims and all.

The main exception is when you have two distinct subject matter experts
working together on a problem. Even then I like to have two keyboards, so it's
not strictly pair programming, but collaborative/synchronized programming,
with expected frequent questions and back-and-forth. I did that once recently
when connecting a C/C++ low latency video and audio streaming library to
Unity3d and C#; I worked with a Unity expert and while he wired up the Unity
side I wired up the C++ side. I laid out what the Unity part needed to look
like, and he told me how Unity interfaces to DLLs on Windows. We frequently
bounced ideas back and forth but were working on different parts of the code.
Worked great; had the integration working in a couple hours, plus or minus.

~~~
dreamfactory2
> to be efficient, pair programming has to produce more correct code... how
> can you not assume they'd be able to create more code with a keyboard and no
> interruptions

I measure efficiency by less code not more

~~~
SomeCallMeTim
>I measure efficiency by less code not more

Really? So if I produce _no code at all_ or just delete code, I'm being the
most efficient, even if the goal is to add new features?

If you're going to pick on semantics, you shouldn't do it with a statement
that's blatantly false on the face of it.

By "correct code" I mean code that is:

* Properly designed, refactored if necessary

* DRY

* Robust

You can't add features to "correct code" while strictly removing line count.
No one is just counting lines of code here; your point is specious.

------
obeka
Hi guys, one of the authors here. Wow, the interest was a lot higher than we
expected

Since you all have been asking, here's a negative excerpt from an earlier
version of this post, which unfortunately got cut before the final draft. I'm
starting to feel like we should write a follow up post now, but in the mean
time, here's this:

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

My take on the introvert/extrovert thing:

I'm definitely one of the extroverts on the team (even though I, like
introverts, get completely exhausted by too much interaction). I thrive in a
communicative environment. We have a pretty fair mix of people on the team,
and we've spent some time trying to find the balance of that, leaving room for
people to leave the mob when needed etc. We usually do not mob for eight hours
a day - reality hits, someone comes in early, someone likes to work late, we
attend meetings, we are all parents and sometimes have to work from home, and
we try to encourage each other to leave the mob at times. My guess is that we
mob approximately 70% of the time. My impression is that our introverts, while
finding it tiresome, are a lot more expressive and take up more social space
in the group than before. The extroverts have worked hard on stepping back and
leaving space. We still have ways to go, but we're getting there.

We are just one team in an organization of many teams working on different
parts and features of the same system. We do not feel that we need to
understand 100% of everything all the time, but our general knowledge has most
definitely improved, and rapidly so. We all feel more comfortable around our
own components than before.

------
badthingfactory
"Here’s the crux of it, typing isn’t the bottleneck in software development"

This isn't a good argument for mob programming imo. This argument pretends as
if the only reason programmers would ever work individually (or in pairs) is
because more keys can be mashed in less time.

In reality, we work individually (or in pairs) so that work can be completed
asynchronously. I can fix a UI defect while Jim fixes a performance issue, and
Sue adds a new feature being requested by a potential client.

Having worked on a large team, and being an introvert - mob programming would
have been a disaster. We had one or two extroverted personalities on the team,
and they would have driven the entire effort while the majority sat and
watched.

It's really cool that this works for someone. Great teams adapt and find a
process that works. However, I would advise leadership at any company doing
mob programming to carefully observe the more introverted personalities on the
team. They probably won't say anything, but they might be dusting off their
resume.

~~~
redrummr
It's not about sync vs async. It's about performance. People who take up
pomodoro-type work tracking are surprised at how hard it is sometimes to get
25 minutes of work done.

I know many people who perform their best when they are training somebody in a
system, or are recording training, or doing a webinar. Pair programming evokes
the same improvements, and it lasts.

When you're being watched you're more present, and you perform better. I would
say that pair programming, assuming no huge personality friction, is more than
twice as effective as single programming. There are some companies that only
do pair programming, most likely because of this realisation.

~~~
badthingfactory
You're making arguments for pair programming which is different than mob
programming. Pair programming is fine. I did it for two years. Like everything
in software, there are tradeoffs, but I had no major complaints.

------
lawn
> Work never stopped.

It shouldn't stop anyway. This way just seems like work got a lot more
inefficient.

> Knowledge sharing increased

Sure... But I imagine it's hard to keep track of it all.

> The overhead got removed.

And a lot more overhead just got added.

> Anyone could go to any meeting.

Where is the win? Meetings should be targeted problem solving sessions anyway.

> Our tooling improved. When working together like this every minute is
> precious, and laborious manual procedures that you just buckle down and get
> done as an individual can no longer be tolerated.

I can see this being useful.

> Individual weaknesses could be overcome.

And individual strengths could disappear.

> Interpersonal issues and friction had to be resolved.

For me it just seems like they would grow and destroy the team.

> Stress levels dropped.

As an introvert I can't imagine a more stressful environment.

> We became more daring and forward.

A fear is that you resist change more and you become less forward.

> We became friends.

I don't think I would in an environment like this. But anyway, what relevance
does becoming friends have with being productive and running a successful
business? It's super good not to hate each other but everyone being _friends_
might even be counterproductive.

Why oh why did you list 10 positive things but didn't even bother listing the
negative aspects? I dunno like this completely destroying your productivity or
it being a completely horrible working environment for introverts?

~~~
enraged_camel
Meta comment: I really hate it when people quote multiple individual sentences
and respond to each one separately (usually with a single sentence of their
own). It sounds flippant and juvenile.

~~~
lawn
Interesting, I haven't thought about it like that. It certainly wasn't my
intention.

------
struppi
I have not had the chance yet to use mob programming on a real project. But I
have used it when teaching workshops and trainings. And it worked pretty well.

The first thing I noticed is that no-one tuned out. When I organized my
trainings so that participants do the exercises alone or in pairs, some would
just not do them. They might have too much problems to even get started. Or,
when pairing with a better developer, just let them do the work. In the mob,
paid attention everybody joined the discussion. [1] Also, I think there was a
better shared understanding of the examples and the solutions after the mob
programming. When working in pairs, I had to monitor 5-8 pairs in parallel and
give them hints and explain stuff. With the mob, I could concentrate on one
screen and join the discussion all the time.

And: Others were helping me out. At one point, a participant said: "I don't
want to take the driver seat, I am no programmer, just a manager". Before I
could even say something, someone else from the audience said: "Come on, try
it. We tell you what to write, and after 10 minutes, we'll change again
anyway".

So, to recap: I really like mob programming for teaching. I think it could
also work well when a team wants to learn something new, has a hard design
session or wants to bring new team members up to speed. I even think it could
work during day-to-day work, but I have never tried that.

[1] Maybe I was just lucky and had a great group when we were duing mob
programming. But I doubt that.

~~~
benten10
This is a really good idea: for workshops.

I don't know about day-to-day or in a classroom setting though. Whenever I did
pair programming in college, one of the partners would often be overpowering
in terms of skills and intelligence, and would spend most of the time getting
the other up to pace. Which is great, except the laggards would often pretend
to understand in fear of being looked upon as stupid.

As someone who's been on both side of the dynamics, yeahh, not sure about
classroom settings. I would love to attend your workshops though!

------
pyrale
Similar experience here at our dojo.

Mob programming is great : we've had people working effectively in languages
they don't know. And so we've had product guys sit with us and practically
transformed them into programmers, able to fulfill their vision.

Issues get identified much faster, and design decisions are quickly discussed
and tried. Because we're able to get feedback on why we're developping, it's
much easier to make the right choice for the right situation.

Test code is much more relevant, and it's much more expressive, too.

> \- Biggest personality wins. I'd worry that whoever had the largest
> personality would drive everything, leading to people being disengaged.

Honestly, we didn't run into this problem at all, maybe because it's a dojo
setting. Since we're used to mobbing, people will usually be extra careful
about it. When there are many people, setting up a fishbowl is a good exercise
to teach people to leave more room to others. I've had deadlocks happen during
pair programming, but in a mob, it's much rarer. Also faster experiment time
leads to much more tries.

> \- Constantly bringing people up to speed. Maybe this is actually a good
> thing?

Definitely a good thing. People asking question is a good predictor of hard-
to-maintain code.

~~~
jgh
"dojo"?

~~~
e12e
I assume they have a kickass system for scheduling sessions and visiting
instructors. I worry about their technique, though, if the spend their time
programming rather than practicing martial arts... /S

------
beat
I used to use the term "mob programming" to describe a phenomenon I saw at a
shop where I used to work. Officially, the process was Extreme Programming,
but the physical layout worked for more. There were two "islands" of
workstations with five workstations each - two of the largest monitors we
could get those days (24"), room for two seats, and spare chairs. Developers
each had small private cubes on the outside walls for email, phone calls, and
such. Coding work was done at the islands. In theory, it was "pair
programming".

What happened in practice was that any number of programmers might be gathered
around a workstation, from a single programmer for a straightforward bit of
coding, to a half-dozen gathered around for a thorny problem or a
coding/discussion session. It was extremely effective!

~~~
badthingfactory
I worked on a team that was set up exactly like this. Like you said, it was
really effective for some ad-hoc discussion about tricky problems. The
knowledge sharing was fantastic and I learned a ton.

The major downside was the chaos. If you were the team expert in some domain,
you usually had someone asking questions about that domain every 20 minutes.
Sometimes programming takes 4 hours of uninterrupted concentration. That work
was very difficult to accomplish.

A small group of us ended up bringing in laptops and separating from the group
multiple (sometimes 5) days a week. We found ourselves having to choose
between finishing our own work, or helping other people finish their work.

------
fiatmoney
I was kind of hoping this would be about calculating loss ratios on protection
rackets and coding rigged numbers games.

~~~
erikb
I'm open for all kinds of new things. What are you talking about? I guess it's
an investment topic? I really don't understand at all what you are talking
about, but I'm curious.

~~~
somehnreader
mob as in gangsters.

------
smnscu
I think this is a fantastic as a 2-3h team activity happening every couple of
weeks, if there is a clear feature/bug to be taken care of. Also, great for
introducing new team members or non-engineers to the codebase. Doing it full-
time does sound weird though.

------
mathgeek
The one thing that is never mentioned, and that I'd like to see the difference
for, is cost to the business.

------
dudifordMann
Perhaps this is good for feature development, or maintenance, but, what about
contracts that deal with wholly new development of a complex system? It seems
like you would want to operate in parallel at least for the initial push
through the architecture and boilerplate structure. Perhaps I am being
disingenuous.

I do love the idea of being able to not let the numerous tedious meetings
interrupt progress.

[edit] Thanks everyone for adjusting my perspective. I am sure junior
engineers (and seasoned stubborn ones) would learn a lot with cradle to grave
development in such a fashion [/edit]

~~~
ajmurmann
Having spent thousands of hours pair programming I would assume that this is
were mob programming is especially valuable. The decisions you make early on
are the decisions that everyone on the team will have to deal with. So if you
do nothing else as a team this should be it. I actually recently had a client
who was lukewarm about pair programming. But they mob programmed on new laying
foundation work fit new services. We pair programmed on three new services
together at the same time. So much syncing had to happen afterwards that mob
programming the foundation would easily have been more efficient and
effective.

------
snsr
Jesus fucking nope. This is a good approach for some problems, and it may work
for this team, for now, but I doubt that this is either sustainable or
scalable.

~~~
mohaine
This.

I've done mob programming a lot and it always seems to break down into either
a few developers working while explaining what they are doing to others or a
developer just typing what other devs tell them to type.

It does work well for knowledge sharing, but that is about it, IMO.

Also, its biggest proponents (where I worked) always seamed to be the devs who
didn't actually do anything and had no real desire but learn. I'm guessing it
is easier to sit in the back of the mob then fake work somewhere else. Always
seemed to have a meeting when there turn got close.

------
perlgeek
How big is the mob? I don't think you want to do this 20 or more programmers
(the more people you have, the more formalized communication structures you
typically need).

I could imagine this working with four or five people, and I'd be worth the
experiment, but I don't think I'd want to do it all the time.

~~~
obeka
(Author here) The team in this post was six when we started, four now (five if
you count our coach who's actually worming himself into the mob now ;) ).

I would definitely not do this with 20. Then again I really wouldn't want to
work in a team of 20 no matter the method.

------
tibbon
I've desire to want to try exactly this. No more 2-week long code reviews,
where 2-3 reviewers debate (slowly) over Github about the naming of a local
variable. No more drawn out A vs B problem solving. No more 2x a day sync ups.
Just put all the stakeholders in a room and crank it out together.

~~~
plgs
You'd still want to do code reviews after mob/pair programming though,
because:

\- the whole team might not be here and needs to review the changes to catch
up.

\- doing the wrong thing as a mob is still doing the wrong thing, and you may
need more eyes on your code to spot that (especially if everyone during the
session was convinced that what was written is right)

\- IMHO, even if 10 persons were involved in writing it, a later review of the
code can still improve quality (because people will actually be reading the
code rather than writing it, which will expose other kinds of issues)

~~~
lotyrin
Who reviews, if the mob consists of everyone? If I participated in developing
a thing, I would have probably already made the oversight, wouldn't see an
issue.

That raises an interesting idea, you split the team, the mob and non-mob, like
learning vs testing data. Dedicate some fraction of the team to the mob, then
rotate out members. It seems like most of the benefits are realized, if people
need skills or compassion for other roles of the project expanded, they get
their turn. If the team is large enough that the mob is a minority, you
minimize the effect of downsides.

------
metasean
FWIW, I'm getting:

uBlock Origin has prevented the following page from loading:

[http://underthehood.meltwater.com/blog/2016/06/01/mob-
progra...](http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/)

Because of the following filter

||meltwater.com^

------
msie
I think if you are passionate about a methodology then you'll make it work. To
truly measure the efficacy of a methodology you'll need some reasonably
unbiased observers from outside the group.

------
chrisp_dc
@teams that have tried this,

Do you find problems with bridging background knowledge across roles?

For instance, you have programmers with 5+ years experience reading/writing
code. They understand basic data-structures & design patterns through second-
nature. Does this create conflict and/or dis-engagement between the
programmers & the non-programmers (management, QA, etc)?

Typically, I work on teams with scarce technical employees. Most of the team
are there offloading work that doesn't require the coding background.

------
enturn
I think the idea from mob programming and pair programming in general is that
a single programmer working on a piece of code is a liability. Everyone is
prone to making mistakes and taking shortcuts especially when rushing for a
deadline or when tired. More people means reduced risk especially if the skill
set is diverse. Though if bugs in the code aren't much of an issue (ie fixing
it quickly results in no repercussions) then one person should be good enough.

------
greggman
I'm having a hard time seeing this as a win. Maybe I not understanding it. You
say 70% of your time is spent this way. Just looking at my own coding there's
just sooooooo much busy work. Add this field on that dialog, pass this
variable to that other class, write that test, etc ... my point being 5% of my
work is thinking about the problem an 95% is typing, testing, iterating. Maybe
I'm doing it wrong?

------
RubyRuby
Intriguing concept, but I find a balance of solo work and group collaboration
to be the most effective method to accomplish goals. That's why our team
invests in weekly or daily (if deadlines make them imperative) reviews of our
successes, key updates, and distractions. This forces us to review and reflect
on work, receive good feedback, and pushes each member in the right direction.

------
jlangemeier
I propose that this be codified as Borg Programming.

A more amoeba like approach could also be an interesting experiment, allowing
for teams to split off and regroup as problems fall into specialty areas,
regrouping to handle tests, acceptance, training, etc. For a smaller team this
may not be feasible, but for a larger group it could be really interesting.

~~~
Zebra_003
HA HA! Author here.

Our team name is "The Borg"

------
ElijahLynn
This looks superfun, can't wait to find a team to try it with someday.

------
cdevs
We would spend to much time arguing until it's just a one man show at work
because one of us believes they know it all.

~~~
cdevs
Annnnddddd you lose out on trash talk #personToMyLeftIsAJerk

------
quickquicker
While it sounds like they made this work for their team, I can't help but be
reminded of the Borg..

------
landmark3
how did they even manage to stay all awake?

------
rhapsodic
No one is as dumb as all of us.

------
askyourmother
Mob programming because they don't trust the individual developers to deliver
by themselves, mob programming because no one has a clue there and they hope
there is wisdom in the crowd, and mob programming because they had nothing
else to do.

~~~
lotyrin
> individuals don't deliver > no one has a clue

Welcome to Earth.

Most teams are not able to attract or retain talent, so they have to focus on
maximizing and concerting effort instead.

