Bulldozers and lightning bolts
In his blog post "What Mob Programming is Bad At", Hillel Wayne discusses the practice of mob programming.1 Although he is generally in favour of the practice, his article focuses on types of work for which he thinks mob programming is not a good fit.
Wayne compares mob programming to the way a bulldozer moves. The practice of mob programming is likely to yield code that has "a lot of weight" behind it; code that is in some sense "better" than code written by a single engineer. Yet it does so in a way that makes it hard to change direction. This makes mob programming useful if you have a relatively clear idea of direction, but less so if the correct direction is still unclear.
He opposes this to the movement of a lightning bolt: "constantly changing direction, with dead ends branching off like streamers". In engineering terms, this is similar to writing a lot of "deep" code and throwing it all away until you find the branch that works. This type of engineering works well when the direction is ambiguous; when much of the code you write will be exploratory and experimental. In Wayne's experience, this is easier to do alone than in a mob setting.
Collective courage
I found Wayne's observations interesting mostly because my experience of mob programming has been different.2
Mob programming has enabled me and the teams I've worked in to be more experimental than we could when working solo. Unlike Wayne, I have not felt that meandering and exploratory coding was harder, or that there was an impediment to throwing code away or doing large-scale refactors. Quite the opposite: most drastic changes of direction in codebases that I have worked on have come from mob programming sessions where we jointly felt that something was off.
I suspect that for me this has been the case because my fellow engineers and I felt more empowered to make bold decisions as a mob than as individual engineers.
In a mob setting, when we realised that a new feature was awkward to implement due to the existing architecture of our codebase, it was easier to ask: how can we design this differently? And it was easier to follow through after formulating an answer to that question. We did not need to talk to product managers to ask for permission. Neither did we have to write up an RFC to propose a wholesale change to fellow engineers. No individual engineer had to justify a delay in "feature delivery" at stand-up, where some stakeholder would ask for a revised estimate, piling on pressure to forego or speed up the refactor.
Knowing this made us braver. It empowered us to listen to our collective programmer spidey sense and pursue our evolving understanding of our domain, knowing that the cost of change was low. Following a thread and realising that it led nowhere, and then throwing away the code, felt like much less of a big deal in the safety and collective responsibility of a mob setting than it would have had it been an individual engineer who did so. The courage to pursue significant architectural changes knowing that the attempt might fail is something I try to instill in the teams that I work in. And in my experience, mob programming has been a significant enabling factor for doing so.
Collective meanderings
But it is not just the element of collective courage that I have experienced as helpful in mob-baed exploratory programming. I also feel that our lightning-bolt-style engineering has been more effective in a mob setting. Having others explore with me reduces the risk of getting stuck in a rabbit hole; we can dig each other out. It also means that we have more pairs of eyes that can spot a promising avenue and convince the others to pursue it.
Most of the architectural "breakthroughs" I have had, have been when within a mob setting we realised that something didn't feel right and we sat down together to re-model our domain and re-think our decision decisions to see where they might be less than optimal. The variety of perspective that we brought to the problem, and having to articulate our diverging intuitions, meant that we ended up with better models.
In closing
I think our experience of mob programming and exploratory programming depends on myriad factors. One of the most important of those is the psychological safety you feel in your pair or mob setting. For me, it was this psychological safety that felt empowering rather than limiting when doing exploratory work. It made me pursue things that as an individual developer working on a ticket I probably would have decided was not worth the risk. But this mental calculus could well have been different in other organisations and engineering cultures.
I also want to agree with one important point that Wayne makes. He calls out that proponents of mob programming are often quite evangelical; they are unwilling to see any downsides of the practice and and chalk any criticism of the practice up to simply not having the right culture. I think this is a blinkered view and stifles debate. Mobbing is a tool, not a religion. It will work for some people in some cases, but it is not a silver bullet. I can think of many downsides myself (not least that it is exhausting, as Wayne also mentions). But for me, the difficulty of writing exploratory code or doing deep refactors is not one of them
1 Hillel Wayne - What Mob Programming is Bad At
2 Now, I know full well that these are preferences, not truths. None of this is meant to contradict Wayne's experience or to invalidate it. I simply want to explore a different perspective.