This past weekend, I had a chance to attend a Mob Programming Workshop with Woody Zuill (@WoodyZuill).
Mob Programming - The Really Short Version
Mob Programming is Pair Programming with more people -- usually between 4 and 8. Just like with pair programming (when done right), the person at the keyboard is typing code based on the direction of someone else. The main idea for this is that the code always goes through at least 2 people's brains before it gets committed.
A mob group consists of programmers, testers, QA, and (as often as possible) a product owner. Meetings are eliminated as everyone is working together and knows the state of the work. When everyone is together, many "blocks" are eliminated (such as "we need more input from the business area before we move forward" or "we need QA to explain the problem they found a bit better").
People generally balk at the idea of so many people working on one thing. (Just like some managers don't like the idea of pair programming because 2 developers could be writing twice as much code separately.)
But I don't see it that way. Programming is a creative process; there is a lot of thought and problem solving involved. So having more minds working on the problem could be much better. In addition, mistakes are caught earlier (since there's more than one person looking at it), and misunderstandings or incomplete information that would normally "block" the process get cleared up much more quickly.
Also, there are no need for code reviews (which no one does anyway) because the code is constantly being reviewed.
Another advantage is that everyone is constantly learning from each other, from simple things like keyboard shortcuts to more advanced language features.
Here's an interesting video that shows a typical day of mobbing that was recorded back in 2012: A day of Mob Programming
This is Not Proscriptive
The main thing that I appreciate about the mob programming movement is how Woody presents the idea. Woody tells about how mobbing developed organically in their environment, and it became very successful for their team. (In fact, the company (Hunter Industries) now has 6 teams working the same way.)
So Woody describes something that they were successful with, but he does not say that all teams should work this way. It is something to explore.
I've known Woody for several years, and I've heard him talk about mob programming at meetups and things like that. I've also known many of the developers at Hunter Industries for several years, and I've been invited down to mob with them for a day. Unfortunately, I haven't had a chance to make to down there (it's about 70 miles from where I live and other priorities get in the way). So when I saw the workshop opportunity come up, and it fit into my schedule, I had to jump on it.
I won't go into the details of the workshop or the exercises other than to say that it was designed to show a different way of approaching collaboration and the difficulties and advantages of that. Much of the day was spent split up into mobs (there were 5 people in my group), and it was a good experience to go through.
I will say that the experience reinforced my view that mob programming is highly dependent on the make up of the teams. There are a couple types of developers who would be toxic to the environment and bring down the productivity. (These are typically the type of people we don't want to work with anyway, but that's a conversation for another day.)
I can also think of people who may or may not thrive in this environment. (I think I might fall into that category; more on that in a bit.)
The idea of mob programming has spread, and there are teams around the world who are using it successfully. My primary experience is talking to the folks that I know from Hunter Industries in Southern California.
As I mentioned, the idea of mob programming grew organically on one of the programming teams. As they developed the idea and were able to successfully deliver software and be very productive during the process, they decided to expand.
Late last year, they set up a new space to handle more mobs. They currently have 6 mobbing stations set up. You can see what they look like in the picture above: 2 80" monitors (a couple stations have 3 monitors), 2 keyboards/mice (which are hooked up to a single computer), whiteboards, and lots of chairs.
Everyone I know at Hunter really likes the environment and they enjoy working there. (And they are hiring if you're interested: Career Opportunities.)
Is Mob Programming for Me?
I'm still not sure if mob programming is an environment that I would thrive in. I've always like collaboration and working with other developers. But these have all been in relatively short chunks. I'm sure that I would be fine for a few hours at a time, or even a few full days at a time. But as an introvert, I don't know if that level of interaction is sustainable for me.
Aaron Griffith (@Aaron_Griffith), who works at Hunter, has written several articles about the challenges of being an introvert in that environment. He really loves working with the mob, but he does find it somewhat draining and has come up with ways for managing that. Here's one of the articles that is worth a read: Mob Programming for the Introverted.
I'm not sure that I could thrive in that environment. I think that if I have a job where I constantly have to think about managing my energy, then I'm probably not in the right job for me. I would much rather be in a position where my job is energizing. The things that I'm doing regularly are extremely draining (and also extremely rewarding), but they are only a few days at time, so it is very manageable for me.
These are just my thoughts based on the experiences that I've had. I'm planning on doing some more exploration. For example, I would like to more closely observe of a mob programming group to see what the levels of interaction, noise, and collaboration are like in a real environment. I'd also be curious to try mobbing over a several day period to see how it would affect my energy.
Mob programming is an intriguing idea. And I can see how the benefits of constant collaboration would result in faster delivery, fewer bugs, and happier clients.
If it's not for me (or for you), that's fine. And I really appreciate that Woody presents it that way.
Are You Intrigued?
If you're interested in exploring this for yourself, you're in luck. Woody is doing workshops around the world on a regular basis. If you're in Southern California (like I am), then you have a chance to attend a FREE workshop at Hunter Industries on August 20th, 2016:
It's always useful to explore different approaches to software development. That's how we find out what's most effective for us -- especially those things we never would have thought of on our own.