Joining a Mob

Most software teams I've had the chance to work or interact with have at least some degree of trouble regarding "knowledge silos". You know you have an issue with silos on your team when work grinds to a halt if a particular developer is out sick, or on vacation. You know you have a silo when one top developer is doling out work to less senior developers while not giving any of them enough of the big picture to truly understand how their part of the code/project works with others. When they finish their small task, they have to get back in line to see what needs to happen next. You know you have a silo when one of your team members is afraid to take a vacation, because everything will fall apart without them there. You know you have a silo when you send an employee to an expensive conference, but s/he winds up answering emails or putting out fires no one else can half the time, vastly reducing the benefits that might be gained from the conference.

Some software teams try to mitigate the risk of knowledge silos by practicing "pair programming" (the folks over at Atlassian may have the most entertaining take on this). Two developers work at a single computer, working on the same feature or issue. There are a number of potential advantages: Someone else is always reviewing your code as you go, so there is no need for a separate code review later on. Your partner is just as familiar as you are with every change you make, so when one of you is sick or on vacation, the rest of the team is not stuck in the mud. When one member of a pair knows more about something, the other gets the opportunity to learn (meanwhile the more experienced developer gets the rewarding experience of teaching and helping a peer level-up).

Woody Zuill took the idea of pair programming significantly farther with something he called "mob programming", and it's not just a theory. He implemented the practice at Hunter Industries, based in San Marcos, CA. Mob programming is a development paradigm where a whole team of engineers (approximately 5 developers, give or take) work at just one computer to develop software. My hunch is that most managers, and even most software engineers would initially have a viscerally negative reaction to this idea. How productive can you possibly be with everyone at the same machine, working through tasks serially rather than in parallel? 

The proof is in the pudding, when it comes to software development, and Hunter has discovered the mob programming pudding is absolutely delicious! The knowledge sharing and learning opportunities for the whole team are absolutely unparalleled. There is virtually zero risk of a knowledge silo developing under this paradigm, so there's no problem with any one person going on vacation, winning the lottery, developing the next Angry Hamsters and striking app-gold, or anything of the sort.

So what is it like on a software development mob? Here it is:  A time-lapse video from the original mobbing team at Hunter Industries, long before I was lucky enough to join the team. It seems a bit unreal, but that actually is what our day looks like, even now that the mobbing paradigm has grown to be 5 or 6 development mobs working in parallel on different projects, or parts of projects at any given time.

As a testament to how happy those developers are, almost every one of the developers you see in that video (which is from 2012) is still on the team, and they are now my co-workers (incidentally, we just made a re-boot of the original mob programming time-lapse, now that we've expanded to as many as six simultaneous mobs!). As a testament to the quality of the results, Hunter expanded the mobbing program from just one team working only on internal applications to a whole department working on both internal and external facing software. And yes, we're hiring, so if this sounds as good to you as it did to me, come have a look at Hunter's job site.

Mob programming is certainly not for everyone, and it is not for every company in every situation. As always, there is no silver bullet. That being said, below are a few of the reasons I love it, and why I think it's an option worth exploring for any team:

• Since starting to work in a mob paradigm, I have never been so relaxed at work. This is not because I have a less intense desire to craft great code quickly, but because I know that everything I do is immediately peer-reviewed. It is because I know that when I have a less-than-ideal solution to a problem, the developer right next to me is likely to pipe-up and suggest an alternative approach, and so on.
• I have never had so few meetings at any job, ever. Since we all code together, there is no need to sit around talking about what we've been doing, and how we hope to integrate our work with everyone else's work. It's already done, and it's done constantly. 
• It is the perfect master-apprentice model of work... Except that you act as both master and apprentice every day, switching roles seamlessly throughout the day as the challenge at hand goes from something you are not well versed in to something that you've got eons of experience with.
• There is a very strong emphasis on collaboration and learning how to craft better solutions to our coding problems. Everyone has a vested interested in leveling-up their fellow mob programmers in order to create better and better code.

If this sounds appealing, give it a shot! Here are a few further resources to get you going:

• MobProgramming.org
• Mob programming page on Wikipedia
• ITWorld article on mob programming