Mob Programming – The Good, the Bad and the Great

I do love the idea of being able to not let the numerous tedious meetings interrupt progress.

[edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]

The first thing I noticed is that no-one tuned out. When I organized my trainings so that participants do the exercises alone or in pairs, some would just not do them. They might have too much problems to even get started. Or, when pairing with a better developer, just let them do the work. In the mob, paid attention everybody joined the discussion. [1] Also, I think there was a better shared understanding of the examples and the solutions after the mob programming. When working in pairs, I had to monitor 5-8 pairs in parallel and give them hints and explain stuff. With the mob, I could concentrate on one screen and join the discussion all the time.

And: Others were helping me out. At one point, a participant said: "I don't want to take the driver seat, I am no programmer, just a manager". Before I could even say something, someone else from the audience said: "Come on, try it. We tell you what to write, and after 10 minutes, we'll change again anyway".

So, to recap: I really like mob programming for teaching. I think it could also work well when a team wants to learn something new, has a hard design session or wants to bring new team members up to speed. I even think it could work during day-to-day work, but I have never tried that.

[1] Maybe I was just lucky and had a great group when we were duing mob programming. But I doubt that.

I'm still skeptical of mob programming, although as somebody who's done a lot of pair programming I'm open to it. But the theory makes sense to me. Early on it's easy to make decisions or fall into habits that cause trouble later. Figuring out some of those initial choices strikes me as the best place to apply a lot of brainpower. Once the architecture is established, I'd expect things would be much easier to parallelize. (But I'd still keep pairing and frequent pair rotation to keep everybody in sync.)

I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them.

Off the top of my head though, I'd be worried about:

- No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets done first). Similarly…

- Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged. Especially when it comes to engineering / structural decisions, if that person thinks they know whats best you're not going to have the chance to try something (and maybe fail) and grow as a developer

- No personal space. You know, maybe it's because I work from home, but sometimes my fiancee messages me a video of a cat being cute, and I might just take 2 minutes off working to watch it, because I'm a human being and not a sack of watery meat sacrificed to the gestalt. I could imagine it would be very awkward to do anything at work that wasn't explicitly working, which sounds pretty suffocating to me.

- Constantly bringing people up to speed. Maybe this is actually a good thing? IDK, but I think if some people are faster than others, or people wander off to make a coffee or whatever, or come in at different times, or leave at different times, you may spend a lot of time going over the same decisions and working through the same problem spaces over and over again. This could be a good thing, or it could be OK that some people know about component X and some know about component Y and there is little overlap.

If anyone from Meltwater is reading this I'd be interested to know if you had any problems (these ones or other), because it sounds like-- ignoring the first month-- this plan has no flaws. Which seems hard to believe.