
Experimenting with mob programming to rebuild the gov.uk Verify front end - robin_reala
https://identityassurance.blog.gov.uk/2016/02/26/experimenting-with-mob-programming-to-rebuild-the-gov-uk-verify-frontend/
======
CraigJPerry
The fact that this worked for me, I later came to learn, was a symptom of an
underlying lack of commitment in the team.

Suddenly no one wandered off into the weeds to deliberate on some
inconsequential aspect of the code (this is a charitable euphemism for went
off reading news sites!) The group drive to progress was greater than the
individuals. As one individual's attention would wane, another would pick up
the slack, keen to show they were engaged in front of their peers and that
would have a self righting effect on the interest of the person who started to
drift.

So for a while we plundered on, amazed by the power of our new tool.
Productivity was up to where it should be, quality was excellent again, the
junior dev was getting a real education too.

I started reflecting on why this was successful - I wondered if there was some
insight I could reuse elsewhere. I slowly came to realise it was just a neat
partial solution to an underlying much bigger problem.

Fixing the underlying engagement problem turned out to be a journey but it was
good fun.

Mob programming has earned a place in my toolbox of life experience, but
there's an inscription on the handle to remind me that its effectiveness could
be a sign of deeper project issues.

To be clear I'm not saying this is the case for the OP's team! It was just one
life experience point I thought was worth sharing.

~~~
robin_reala
Interesting! Can you explain more what you did to fix the underlying problems
you found?

------
patricjansson
Mob programming is the go to solutions at work. We have been using mob
programming for a couple of month for specific parts of existing and new
projects and it still surprises me how good it is. I never liked pair
programming and when I heard of thought this was the same thing, just more
wast of time. But I was wrong. You should try it out, its free you know, no $
to pay.

But as always we are people and people like different things, but with mob
programming I think you have a really good chance of succeeding. Just remember
to take 5 min to explain how to do it before you start.

~~~
Kiro
How is it free? Seems like the most expensive thing ever. 10 programmers using
one computer.

~~~
adwf
How much of programming is actually typing code though? I think that less than
5% of my time is actually typing, the rest is thinking.

So if you go with mob programming and have one guy doing 50% typing whilst the
other guys are thinking. In theory it could be just as efficient, with the
added benefit that everyone understands the system and is onboard with the
design. Plus the usual benefits of pair programming: you can train juniors,
many eyes to catch the bugs, etc...

------
bshimmin
I can imagine this being useful at particular junctures in a project - perhaps
it's real crunch time on a critical feature, where everyone needs to put their
minds together to solve one difficult problem, everyone is months in and on an
even footing, and you just need one guy to type it all out; or perhaps a
brainstorming session where you're trying to throw together a workable basic
prototype very quickly; or even debugging and fixing a complex issue might be
well-served by this approach - but I can only imagine doing this day-in, day-
out would drive many people absolutely insane. I'm sure there are genuine
reasons why many developers like to sit at their desks with their headphones
on and the volume turned up (even if it does annoy the hell out of managers).

In my own team, we periodically pair up to do peer review and testing, and
sometimes prototyping of new features. I try and avoid doing this more than
about once a week, though.

------
EliRivers
_We decided to adopt mob programming as we believed it would help establish a
shared and consistent understanding of how the new frontend would be built._

Okay, now I understand. It's a way to solve the problem of very few people
understanding the design. Seems an expensive solution, but the expense of your
programmers not understanding the design of what they're working on can be
pretty high as well, and good documentation is hard to write and sometimes
hard to make people read. I don't know if it's _that_ hard, but this would
work as an alternative.

I suspect this only works when the problem being solved is pretty simple, or
isn't actually a "problem" but only a question of layout and design.

~~~
ebiester
At the beginning levels, yes.

I've been in a workshop with Woody Zuill, talks by Arlo Belshee, and my team
has some mob programming under our belt. We don't use it exclusively, but it's
a great tool to have in your toolbelt.

We have a skill-diverse team -- a tech lead, 4 web and backend developers, 2
iOS, 2 Android, and 2 QE (one of whom is moving toward a backend developer.)
At any time. we may have 1-2 support tasks and a project. We have a range of
junior to senior developers.

Sometimes, we have sufficiently broken-out work that we can keep everyone
engaged at a single-stream, but even that's a polite fiction. The junior
developers get stuck, which has them spinning their wheels for periods of time
until they realize they're stuck, then bring in a more senior engineer whose
work is then interrupted. Sometimes, the senior engineers get stuck in
analysis paralysis where a discussion would be more productive. That jumps
into an impromptu meeting which solves the problem but interrupts half the
team as anyone interested hashes the problem out.

Then, there's the tech lead (me) who gets interrupted constantly to the point
that it's not worth taking tasks sometimes. There's production support, cross-
team support, and intra-team support. That isn't to mention the meetings. :)

And sometimes, the tasks on a project aren't parallelizable, especially at the
beginning. It used to be that everyone would get into a giant room and discuss
design, then break it out into tasks and go. Mob programming can replace that
phase by having everyone in that room do the work to flesh out the idea.

Then there is the work to peer review a decision and test it. When a ticket is
in peer review or test, that developer is in full interrupt mode. They may get
work done on the next ticket, but it is historically a period of low
productivity for a developer.

The fundamental hypothesis of mob programming is that the interruptions of a
team combined with the overhead of process are high enough that condensing to
a single workstream+ actually doesn't reduce productivity.

If a team is working on a mob, and a production support request comes in, I
(or one member of the team) can peel off of the mob and figure it out. If a
support ticket comes in, a member of the team can peel off and work on it,
have it reviewed by another in the mob, then tested by another, and the single
stream workflow is still going. It becomes easier to catch up on what has
happened than return to it.

When working on hairier problems, it turns out that a distributed memory works
better than holding it in one individual's head. It turns out that it can feel
slower but the work happens quicker. Sticking points are resolved quicker
rather than devolving into analysis paralysis.

It seems counter-intuitive that the work doesn't slow down, but the decrease
in peer review and testing time (because QE has been involved from the
beginning thinking about testing scenarios and how to test) that the reduction
in overhead compensates for more people working on the same problem.

There are other paths to streamlining a team's efficiency, but this is an
interesting one worth trying in some cases.

------
mundanevoice
I think it's important to take regular breaks because pair programming or mob
programming requires a very level of high energy. The code quality definitely
improves because of many eyeballs into the problem and provides an instant
feedback for the code written.

------
aikah
First time I hear about mob programming.

> [http://mobprogramming.org/](http://mobprogramming.org/)

so it's pair programming, but with 10 people in front of the same computer ?

------
CM30
Have to admit, when I read 'mob programming', I expected something closer to
how open source works. Or random people on social media committing code for
the site in a big free for all.

I still don't get why this 'multiple people on one computer' thing would be
helpful though. I mean, couldn't a team working on the same site on multiple
computers do pretty much the same thing with the bonus of a quicker turn
around? Seems like micromanagement gone insane...

~~~
IneffablePigeon
Have you ever tried it? Most people seem to have a similar first reaction
(myself included), but it's a surprisingly useful tool for certain problems.

~~~
CM30
Haven't ever really worked with a big enough team for it. I mean, current
workplace has exactly two people doing web development, and the previous one
had maybe between one and three people per project. If we tried to work like
this, nothing would ever get done.

------
exdevbath
This explains a lot. The gov.uk site is such an unusable mess it can only have
been designed by a mob.

In my view mob/pair programming is a very inefficient way to work. I guess it
depends on the people, but personally I think much more clearly alone than in
a group setting. Have many eyes on code is great and I'm all for peer review,
but a mob making decisions is a recipe for group think and the less dominant
personalities (and probably best coders) being ignored.

~~~
Ace17
"the less dominant personalities (and probably best coders) being ignored" WAT

How are you going to get your skills recognized by your teammates, if you
avoid working with them? Of course you're being ignored by them: you're
ignoring them the rest of the time!

In my experience, in a context of technical arguments, great speakers with
doubtful technical skills don't last very long against shy highly-skilled
techies pointing out relevant weaknesses in the proposed solution, and asking
tough questions.

~~~
douche
The bullshitters win, never forget that. Reality doesn't have any bearing,
when they are parroting the words of what those with real power want to hear.

------
fallingbadgers
Needs more pitchforks :)

I like this as a disrupter of rote and a way of getting many eyes rapidly in
the same place.

Now we just need a Twitch channel...

