March 14, 2024

What Mob Programming is Bad At

Bulldozers vs Lightning Bolts

Pairing is two people working together to write code, while mobbing is three or more. Pairing has been part of the programming milleau since at least the 90's (with extreme programming), while mobbing is more of a 10's thing. I'm going to use them interchangeably from here on out even though they're not interchangeable, because I think everything I'll say applies to both.

Proponents of pairing/mobbing attribute all sorts of benefits to it: higher quality code, more shared ownership, no more need for code review, even (in the most extreme claims) eliminating bugs entirely. Naysayers claim it slows team velocity down, is emotionally exhausting, and only works with very particular personalities. To which the advocates respond that if mobbing doesn't work, it's a problem with your company culture.

And things kind of go in circles from there, because you can't go anywhere from "it's a problem with the culture." I've made this same mistake in the past too! "Company culture" is the "wizard did it" of software techniques: you can explain the success or failure of anything with "culture". If you think the only possible problem with your $THING is "bad culture", then you're saying $THING doesn't have any problems, which means it's snake oil.¹

Now overall I'm mildly pro-pairing. The last couple of places I worked at paired regularly, and when I consult with clients, I "mob specify" as much of the project as possible. This is because pairing is really, really good at knowledge sharing. It's a great way to get people up to speed with a new language, or domain, or even a section of a codebase. I even did a day of mobbing with Hunter Industries to understand it better.² So while I think the loudest people online make overblown claims, I still mentally treat pairing/mobbing as "underleveraged techniques" along with stuff like formal methods and metamorphic testing.

So here's one thing I just cannot make work with pairing: optimization.

I am always better off optimizing code on my own than as part of a mob. I noticed this a long time ago, but I think I finally figured out how to explain the reasons why.

Bulldozers and lightning bolts

In practice [mobbing] usually feels like a bulldozer rather than a racecar - unstoppable and thorough. (source)

Bulldozers are "unstoppable" because they have high momentum, which is a function of both how heavy something is and how fast it's going. So if mobbing is like a bulldozer, then it's low-velocity, high-momentum. The mob writes less code than a bunch of independent developers but there's a lot of weight behind the code. It's more likely to be "good" code.

Something with a lot of momentum isn't just hard to stop, though. It's also hard to change direction. And in optimization I don't know the right direction. We can't easily predict how an attempted optimization will affect the overall program performance. If I see twelve ways of making something faster, six might have no effect, two could have negative effects, two could lead to minor improvements, and two could lead to order-of-magnitude improvements as long as you didn't do the minor optimizations. That's why benchmarking impact is so important!

The best way out would be to try all 4096 possible combinations of optimizations and then throw away 4095 of them. Lots of code written, lots of code thrown away. I want high-velocity, low-momentum. Instead of feeling like a bulldozer, my mind needs to feel like this:

The path to fast code is a stepped leader, constantly changing direction, with dead ends branching off like streamers. Sometimes the dead ends can be just as long as the final path but still go nowhere. You write a lot of code, you write a lot of deep code, and then you throw it all away.

That start-stop motion doesn't work in group programming. It can if I know exactly what optimizations we need to make and it's just a matter of making them. That'd be something like fixing an N+1 query or replacing one algorithm with another. Then we have a direction and momentum is helpful.

Otherwise I much prefer to figure out optimizations on my own and then take my conclusions back to the pair to explain. Mobbing is good for knowledge sharing!

Generalizing this

Now you might argue "mobs throw away code all of the time." The difference is that it's "short-generation". They might throw away a few minutes of code but they're worse at throwing away a couple hours of code, which is sometimes necessary in optimization. The pattern I see is that mobbing is at its worst when code has

1. A low chance of "surviving" to prod
2. A long lifespan, even if never survives

What are some other places like this? Exploratory programming. Some kinds of deep bugfixing and refactoring. Local refactors ("pull this into its own function/class") are easy and common in the mob. Complex refactors ("redraw the separation of concerns for these four modules") are harder. Anything where progress happens in sudden jumps and lurches than through a continuous motion.

(You can adapt some pairing practices to handle these better, but IMO that's sensible for people who already prefer working in a group. If you don't pair or only pair part-time, this is something that you should keep doing solo.)

If you disagree come fite me

I did some searching for articles on how to pair/mob on optimizations and couldn't find anything. So if you think that no mobbing is great for writing performant code, don't email me, put it up somewhere online and then email me.

Also, if you tried pairing or mobbing and it didn't work, you should also put that somewhere online. Right now all of the people who are writing publicly about it are evangelists.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.