(This post is part 2 in New Relic’s 6-part mob programming series, which we call Taming the Mob.)

I like mob programming and I like metaphors. I like mobbing because it helps my engineering teams ship great software reliably and consistently. I like metaphors because it’s fun—even in professional settings—to map seemingly unrelated concepts onto each other to help communicate complex ideas. Recently, while preparing a talk about my team’s practices, I went looking for the right metaphor to describe mob programming. I wanted a metaphor that would highlight the utility of mobbing for a room full of fellow engineers, engineering managers, and product managers, most of whom had likely heard of mob programming but might not appreciate its benefits.

I used to summarize mob programming simply as pair programming with more than a pair of programmers. Alternatively, I would describe it as an extremely literal adoption of the principle that a development team, rather than individual engineers, should be the unit assigned to a task. These nutshell descriptions communicate the basic shape of mobbing, but they don’t do justice to exactly how the practice has helped my team succeed.


The campfire metaphor

The metaphor for mob programming that I’ve come to like best is that it’s like a group of campers tending a campfire. When you’ve got a good campfire going, campers can come and go, but the larger group never leaves the fire unattended. Likewise, during a mob programming session, an individual engineer may be drawn away from the mob, but the group will continue to attend to the task at hand.

Like a group tending a campfire, a mob maintains a sense of continuity. Our collective focus keeps the fire burning, and cultivates a shared space where we can do our best work.

Keeping the fire burning

During the workday an engineer can be interrupted from a task for any number of reasons: they may be on-call and need to field a support request; they may need to attend a one-on-one with their manager; or they may need to attend to any of life’s other demands. If this engineer had been working alone, any task they had been working on would be left cold until they returned. A mob, in contrast, will surely miss that individual’s contributions but will nonetheless continue to make progress on the task in front of them. Mobbing ensures a team’s focus stays resilient against the temporary absence of an individual.

As campers move continuously to and from a fire, great conversations typically happen—campfire bull sessions are legendary. The conversations within our programming mob are less freewheeling and are often structured around critical questions, but remain an integral part of the process:

  • Are we making the progress we thought we would?
  • If we’re getting drawn into other work, is it because our approach isn’t working?
  • Is the task more complex than we anticipated? Do we need to communicate that to our engineering and product managers?
  • Is it time to stop arguing about our preferred Ruby hash syntax?

Questions like this help us understand why we may be losing momentum on a task, but, more importantly, they give us a mechanism for holding each other accountable for getting the task done. When we keep these questions in mind, we’re often able to pull each other back from common engineering pitfalls, like:

  • Bikeshedding: Are we spending more time discussing trivialities than making important decisions?
  • Yak shaving: Are we getting so bogged down in small tasks that we’ll never finish the intended large task?
  • Falling down rabbit holes: Are we getting lost in a winding series of tangents that are only peripheral to our main task?

No mob will ever be completely free from all of these pitfalls—software development is hard, and none of us are perfect. However, while I’ve seen our mobs suffer these distractions for minutes on end, we’ve never misapplied our efforts for days or weeks, as I’ve seen happen plenty of times to individual engineers (myself included).

The campfire as shared space

The campfire is also a place of safety. It provides a primordial feeling of security and comfort: it gives off heat against the cold and light against the dark. Mob programming provides a development team with a comparable feeling of safety by cultivating mutual trust among team members. As campers tend to gather around the shared security of the fire they’ve built, mob programming draws engineers into collaboration rather than pushing them away from each other.

If you ask an engineer working solo on a task about their progress or focus, they may react defensively or assume you’re unfairly challenging them. Mob programming gives teams a shared space and structure to raise such questions safely.


By building trust in a group we also make it easier to build trust in our one-on-one relationships. Sometimes it just doesn’t make sense to mob; sometimes we just need to split up if several of us are struggling to stay engaged—after all, no practice is an ideal fit for every task. Nevertheless, I’ve found that our dedication to open conversation and our sense of collective safety carries over to our  solo work, and that helps us hold our team together even when we’re working on separate tasks.

Mobbing helps us do our best work, within or outside the mob.

My team and I have come to rely on this campfire metaphor. It helps us explain what’s good about mob programming to other engineers and engineering managers. By continuously applying the team to its most important task, by keeping us from losing or misdirecting our focus, and by creating a sense of safety that holds our team together, mob programming helps us accomplish far more as a group than we could from the sum of our individual efforts.

Don’t miss the other posts in our Taming the Mob series:


Watch the video below to hear New Relic engineers talk about the principles of mob programming and how it’s impacted the software development process at New Relic.


Nate Borrebach is a Senior Software Engineer at New Relic on the Account Experience team. He currently builds features for account-management and usage data, but he’s perennially interested helping his team ship great software faster. He’s an enthusiast of the symphony, the Oregon outdoors, and happy hours. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!