
I did mob programming every day for 5 months - petercooper
https://medium.com/comparethemarket/i-did-mob-programming-every-day-for-5-months-heres-what-i-learnt-b586fb8b67c
======
poulsbohemian
Contemplating this article over my coffee just now, I realized what bothered
me about this pair programming extension. There are really two divergent
schools of thought in software, that only get acknowledged periodically. There
are those that see software as a _factory process_ , where developers are
essentially interchangeable cogs, tasked with churning out an amount of work
each day. I would submit that much of "Agile," despite being well-intentioned,
falls into this camp. The alternative view is to view software development as
an engineering _profession_ , requiring specialized education and knowledge,
where individuals are respected in the same way as doctors, lawyers,
accountants, or other types of highly-skilled professionals. In this model,
developers might come together in an exchange of ideas or information, but
otherwise have _personal responsibility_ for their own outcomes. These
conflicting schools of thought would seem to be at the root of many of these
discussions of methodology and practice, where for some things like pair
programming and stand-up meetings are essential, and for others, untenable.

~~~
tsumnia
I think a good follow up, if you have the time, would be to read through the
BBC article that is also on the front page about the benefits of being a
loner. The two articles seem to be arguing for different sides of the same
issue.

~~~
poulsbohemian
Thank you for the suggestion!

------
yawgmoth
We do mob programming for my current project, once a week, for about two
hours. It is most useful for new features where people can get design
paralysis, we've found. The benefit of familiarity are tremendous. The mobs
have a topology, though - you can't just pull someone in from the other side
of the office and say "alright John let's get rollin'". On the other hand,
Architects (and other technical leaders) are good mob drop-ins. They ought to
be looking at my code base anyway.

It has also helped achieve coherency in design patterns, stylistic differences
(which we also use tools to enforce), and testing practices.

I get the kneejerk reaction of "it's hip or buzzwordy" but this is one that
has worked well for us.

------
benbristow
Never really liked mob programming at my old job. Just made me really
distracted and made me feel like I wasn't needed as in my head I knew I was
working with talented developers who could do what we were doing by
themselves. Basically just ended up being a human typo spotter.

One thing we found useful though was using a timer for the 'driver' (person
behind the keyboard). I made a terminal one here:

[https://github.com/benbristow/agile-
timer](https://github.com/benbristow/agile-timer)

It's more designed for Mac as it uses the 'say' command but could be tweaked
easily for Linux users.

Although when I started at my new job I would have found it useful. Trying to
figure out custom frameworks where the documentation was in a few people's
heads wasn't fun.

------
nartz
Another buzzword - this us simply pair programming but with 3 (or more)
people? Frankly, I find working in this way to work but in an extremely
inefficient manner. A simple code review is often much more insightful, more
efficient, and easier to communicate versus piling around a single keyboard -
just some thoughts.

~~~
neor
I don't agree, pair/mob programming has its benefits.

In the early stage of starting a project you need to set up the structure of
the application you are going to build. The architecture, and rough outline of
where what needs to go.

By using mob programming we've been able to get an entire team ready to go at
full speed in no time. Everyone knew the thought behind every decision made,
and everyone had enough knowledge of the structure to hit the ground running.

That is way better than having the lead dev or architect do that work on his
own and then having to spend time to explain it all to the rest of the team.

Mob programming has its advantages, but I wouldn't want to use it too often.

~~~
mey
So what's the difference between that and gathering around a whiteboard and
doing some design/planning work?

~~~
neor
To me personally; not much.

The main difference is walking out of the room with a pull-request setting up
the structure in code instead of walking out the room with a photo made of a
whiteboard.

~~~
jeremiep
I find that starting new projects with multiple people right away is almost
always a recipe for disaster, or at least drastically reduces the potential
quality of the project before even writing the first line of code.

Maybe it works for small projects or teams of mostly junior developers. But
for anything remotely complex I can say from experience the architecture won't
be ready in a few meetings but rather after much hammock time.

That architecture will then become a main factor in your productivity,
maintainability _and_ performance. These 3 are very, very hard to optimize for
once the architecture is in place.

Other than for code reviews or mentoring junior developers, I've never seen
pair/mob programming works with quality results. Its nearly impossible to
solve complex problems when outside the zone, and its nearly impossible to get
in the zone in a pair/mob setting.

~~~
ajmurmann
I think at least the zone part depends on personality. I have a much easier
time getting in the zone when pairing and riding off each other's ideas.

------
mordymoop
I'm gonna start pushing for calling it "hive programming".

~~~
Osiris
Good idea. I'd never heard of mob programming before. When I clicked the
article I expected an article about programming _for_ the mob.

~~~
mirimir
Yes, I was thinking about methods for creating and managing mobs. But then,
I've read Burroughs.

------
pg_bot
Too many cooks spoil the broth. Effective teamwork does not mean we all need
to work on the exact same thing at the same time. The best teams I've been on
have people who are "t shaped" and have the autonomy to self organize. It's ok
to collaborate but it's usually best to communicate what needs to be done,
split up the responsibilities, and then complete the work independently. In my
experience smaller teams output higher quality work at a faster rate. Bigger
teams have less accountability and are prone to wasting time bike shedding.

All of the problems the author states are symptoms of other issues in the
organization which will not be solved by this particular style of group work.
Incomprehensible code is still incomprehensible regardless of whether it was
written by 1 or 10 people. Everyone is bad at this to begin with, how can you
expect to get better if you have someone else solve all of your problems?
Going through a bit of a struggle is a good thing, as it gives you confidence
that you can solve new problems as they arise.

~~~
chrisweekly
>"T-shaped" ?

~~~
mhink
It's a phrase usually used to refer to developers who have a broad base of
knowledge (the horizontal stroke of a capital "T") as well as a single area of
particular specialization (the vertical stroke of the "T").

~~~
chrisweekly
Right on. Thanks.

"Jack of ~all~ many trades, master of ~none~ a few."

------
sjtgraham
Sounds like something a consultancy would insist on to juice contract value.

------
luizfzs
I see a _huge_ opportunity to mentor Junior devs by doing this.

~~~
poulsbohemian
Completely agreed, but this is probably the only real use for this technique.
For experienced (read: expensive) developers, the cost overhead of having two
or three developers working on one problem (which is likely a one-person task
anyway) is too great. I'm certain proponents would push the quality angle --
that two or three pairs of eyes and brains focused on the problem improves
quality -- but there are other ways to boost quality while maintaining a more
realistic productivity and cost structure.

For less-experienced developers though, this would be a great way of building
team cohesiveness, training/mentoring, plus likely boosting productivity.

~~~
taoistextremist
I would argue it's also useful for new team members in general, or for teams
that have in the past been unorganized. At my current job I've spent a lot of
time refactoring code so that there's some more unity among everything,
because everybody does their own thing and doesn't really collaborate, which
makes maintenance a pain in the ass. Something like this that kind of forces
people to work together and create some kind of unified style could be very
beneficial.

Not to mention when I've seen experience developers show something they've
been working on for the past two weeks, only to be told what they've shown is
a disaster because they never had any other eyes on it to question their
design decisions.

------
blakecaldwell
I can see this for a team of interns on a summer project, but not senior devs
that don’t really get stuck that often, or know to involve someone for the
brief periods where they need a second set of eyes.

------
passivepinetree
I work for a company that almost exclusively does mob programming. As in I'm
in a mob 95% percent of the day, every day.

What I miss most is "the zone." Pretty much every single line of code requires
a verbal interaction with my coworkers. I used to love the feeling of coming
up for air after 2 hours of visualizing abstractions inside of my own head,
kind of like that feeling of reading a novel and suddenly coming to and
remembering all of the action like a movie had occurred in my imagination.

Programming used to be unbelievably fun because of that. It's still fun, but
some of the magic is gone.

------
beersigns
I've had a lot of success with paired programming in different team/project
environments and really have only done 'mob' experiments. I didn't find there
to be a lot of benefit to mobs vs pairing unless the goal was to make sure
every team member was highly aware of what was going on in a specific
commit/feature-branch.

I definitely think ad-hoc mobbing has it's place and most if not all big
design/redesign work the team undertakes should be in a mob form. I'm not sure
I could see it being a good practice day to day for most teams/projects
though.

------
sj3k
As a junior dev only a couple years into programming I love pair programming.
I spend way less time stuck. It's been life changing for me.

------
almostarockstar
I’ve just finished a 4 year PhD, working alone. Now, I’m building my company
building software, but I’m currently a one man show, and again, working alone.

Do you reckon 3 people in a mob is more productive in the short term than 3
people working independently?

I wonder if 3 people who typically work independently could time-share each
other to work on projects in a mob.

~~~
megaman22
Unfortunately, you're probably broken at this point. Too much time spent in
the productive bliss of solitary work breeds unrealistic expectations when
pulled back into the conformity of collaboration. It's like shackling a
thoroughbred to a plow.

If you've got VC money to burn, sticking a whole squad of expensive
programmers in a room and gating their output to slightly more than a single
person might be a reasonable option...

------
deadmetheny
Based on the headline I expected this to be someone talking about programming
for organized crime. Imagine my disappointment when it's just another bloody
buzzword.

------
nunez
We have been doing mob programming for the last month or so. It works well,
but everyone needs to be engaged. Otherwise, it's just a distraction.

------
bassman9000
I can't wait for recruiters to incorporate this to their lingos

------
jcadam
I've never heard of "Mob Programming" before coming across this thread. It's
as if somebody looked at pair programming and said "This sucks... but I think
I can make it suck _more_."

Collaborate on architecture, interfaces, design, etc.. sure. But, as an
introvert, sitting in a room amongst a mob of code monkeys screaming and
flinging feces about the room whilst trying to share a single keyboard doesn't
sound like the best way to build good software. I'd have a blinding headache
after an hour of this sort of thing.

~~~
jfroma
I am not introvert but I feel very uncomfortable doing pair programming
(specially with one keyboard).

When I am driving some times I get questions about things that I don't care at
the moment, why I am using vim/sublime this way, why I named the variable like
that. This causes me to lose concentration. If I am "navigating" (as the
article mentions) I try to not make many comments but I feel very stressed
about the other person not solving the problems the way I would.

I am very open to brainstorming meetings etc, but then just let me go back to
my computer in my space to write code. Then I send a PR to someone in the team
for review and we can discuss about it.

However there are scenario where I think pairing is very useful, for instance
when doing risky changes to infrastructure. The driver share her screen and
then it tells the other people watching every action before executing, like "I
am going to switch the DNS record now to X.." and the copilot answer "go
ahead", "I will wait 2 minutes"..."I am taking down this load balancer.. "

~~~
nathanaldensr
I think you identified the best use of pairing: high-risk changes. Avoiding
costly mistakes is easier with "another pair of eyes." Pairing on the creation
of yet another DTO has very little, if any, value.

------
jarsin
T minus 1 hour until every job posting has 10 years of Mob experience
required.

------
s73v3r_
This is just pair programming, or "swarming".

And, I hate it, especially when told to do it, as opposed to when it happens
naturally.

------
tytytytytytytyt
> Given that most programmers get in hot sweats just thinking about the idea
> of working with other people

Nice.

~~~
dang
It's a dumb line, but please don't post unsubstantive comments here.

------
tahw
A person that struggles with CSS and performs better when two other developers
are telling them what to do should probably just not be in this industry at
all. This sounds like a nightmare for any competent developer.

~~~
chowells
If I have any kind of hard CSS problem, I ask someone else on the team to
handle the styling. I could do it, but it would take me 3x as long and make me
miserable.

No one else on the team can handle integration with federated identity systems
the way I can, though. I know all the technologies and their security pitfalls
that have to be coded around. No one else knows those things. Are they
nightmares for competent developers and not people who should be in the
industry?

~~~
trhway
both - CSS and federated identity - are basic stuff that a competent developer
should be able to handle efficiently.

