Whoever gave Mob Programming its name clearly wasn’t in marketing. Who would want to be in a mob? The word mob conjures images of smashed glass and looted stores — the population of Springfield lined up with pitchforks and torches.
Mobs really are the opposite of what you would want from a successful programming session. Mobs are disorganised, prone to rash decisions, angry and unwilling to compromise. Mob programming however is none of these things.
So What is Mob Programming?
So what exactly is mob programming? Put simply: 3 (or more) developers, one keyboard. No, that’s not something weird that you’ve seen on the internet. It’s about working collaboratively towards delivering high quality software.
Given that most programmers get in hot sweats just thinking about the idea of working with other people, I’ll delve into more detail as to what that looks like. Imagine we have a developer, Steve. Steve works on an app where users can view recipes. One day Steve is tasked with adding a ‘favourite’ feature to the app. With this feature users are able to save recipes to a a private list called ‘my favorites’. If they want to view a saved recipe again, they can simply open the favorite list and select the recipe.
Steve wants to use mob programming to implement his feature, so he books a meeting room and asks his colleagues John and Sarah to join him in a mob. John and Sarah show up to the meeting laptops in hand, ready to take on the challenge of the favorites feature.
So at this point, Steve needs to lay down some rules (yes mobs have rules). The rules might be something like this:
- At any given time one person is the ‘Driver’. The driver is the person with the keyboard and mouse, the driver is the only person allowed to modify the code.
- Everyone else takes the role of the ‘Navigator’. Whilst the driver spends a lot of their time occupied with the physical task of typing, the Navigator has all the time they need to think, review, discuss, describe. And that’s exactly what the navigator should do.
- Everybody swaps roles — often. No, this isn’t some ‘everybody gets to play’ stuff you heard in primary school. If people stay in one role for too long they can become fatigued. if they have a favourite role then when they’re not in it they can become bored.
And that’s it — you now know about mob programming. Add it to your CV.
Ok, I get what it is, tell me more.
If you’ve made it this far down your probably thinking “Why is this guy banging on about mob programming? Google literally comes up with 500 explanations already.” Simple, I’ve been doing it every weekday for 5 months. Here’s what I have learnt:
It’s Actually quite good
I remember when I learnt about mob programming for the first time. I was 19, stuffed in a room full of deodorant free students, in a building that looked as if it should be earmarked for demolition (fun fact: it was). The professor had just finished explaining our coursework on data structures. In the end he quipped “You can do this alone or in a group — In Industry everyone is doing programming in groups, they call them mobs”. Oh God I thought, There’s group work in adult life too.
What’s amazing is that every time I introduce the concept of mob programming to a new person, the same sense of dread seems to cross their face. Keep your group work to yourself.
Here’s the bad news — you’re doing group work already. At work you work in a team, you ask them for help, they review you code. It’s the combination of all your efforts that dictates whether your project succeeds or fails.
As soon as you understand that you realise what mobbing really is. It’s not doing more group work but the same amount. The difference is that all of the interactions with your team are going to become super easy, no more wondering what other people are doing, no more.
Mob programming helps you know your colleagues better.
If you ever look up from your computer, you might notice that there are other people around. Turns out they have lives too! But seriously, when you’re interacting with people 9–5 you get to know them a lot better than you would otherwise.
As programming is a job not a social club we should be more practical about this. Teams that interact well together perform better. It’s a fact of life, hence all those off-sites and team building exercises. Mob teams don’t need team building exercises because the teams already work well together.
Being remote is no excuse not to join in.
“But I work remotely, I’m never going to be in the office to mob with anyone”. Bad news mate, I work remotely all the time. It turns out that in this thing called the 21st century remote working apps are a dime a dozen. My favourite: Slack video call. It has all the features you need: you can share your screen when you’re the driver and use your voice to be the navigator. But maybe your company doesn’t have slack, maybe you have something like webex where setting up a call takes 3 years and a research team. In that case whack open a appear.in session and stop making excuses to be unproductive.
I spend more time programming, because I spend less time stuck.
So I’m going to admit something, I’m bad at CSS, not just bad — BAD. so you can imagine when I’m working on a project, say my website (coming soon) , I spend hours of my time bashing my head against the wall trying to work out why my divs won’t align (seriously why?).
When mobbing though everything is different, I don’t get stuck on CSS because there’s always a second and third pair of eyes there to help. This means less time banging my head against the wall and more time solving problems.
There’s no such thing as ‘my corner’ of the code.
Let me tell you a horror story, It’s a story of that bit of code. You know the one. It was originally written by Frank, just Frank. When there were bugs in the code, Frank fixed them. When new features we’re needed, Frank added them. Nobody else in the team knew how the code worked. Just that it did. If it didn’t Frank was there. Well one day Frank wasn’t. Frank moved jobs and got a big raise, good for him. You however are left with a part of your system that nobody understands and nobody wants to touch, enjoy.
Mobs however write things as a team so there’s never a mystery area of the code. If an area is a mystery now then mobbing with the writer will soon bring the mystery to an end.
So that’s what I’ve learnt (so far) about mob programming. To be honest I’ve been genuinely surprised just how much I’ve embraced it both as an enjoyable way to work and a way to approach complex technical problems. Of course at this point you’re probably more concerned about how I missed that important positive (or drawback) out! — Thank God there’s a comment section.