Mob Programming
Also known as: Ensemble Programming
Whole team works on the same thing at the same time, in the same space.
Mob Programming was developed by Woody Zuill and the Hunter Industries software team beginning around 2011 and presented in Zuill's 2018 book Mob Programming: A Whole Team Approach. The practice extends pair programming to the entire team (typically 3-7 people) working together on the same problem, at the same time, on the same computer, in the same space (or in distributed contexts, the same shared session). One person at a time is the driver (typing), with the rest navigating; driver rotation is frequent (every 5-15 minutes typical) following the principle that 'for an idea to go from your head into the computer, it must go through someone else's hands' (strong-style mobbing). The practice's apparent extreme inefficiency (paying 5-7 people to do one person's work) is challenged by claimed benefits including elimination of code-review delay (review happens continuously), elimination of knowledge-silo effects, dramatic reduction in handoff and waiting time, accelerated team learning, and high-quality decisions through real-time consensus. The 'Ensemble Programming' rebranding (Maarit Laanti and others) emerged in the 2020s to remove the militaristic connotation of 'mob.' Empirical evidence on mob programming is limited but practitioner reports are largely favorable for specific contexts including legacy-code work, complex problem solving, and onboarding.
Core components
- Whole team (3-7 people) working together
- Single workstation/shared session
- Single driver at a time, rotating frequently (5-15 min)
- Strong-style mobbing ('idea must go through someone else's hands')
- Continuous review and decision-making
- 'Mob' renamed to 'Ensemble' to remove militaristic connotation
- Particularly suited to legacy code work, complex problems, onboarding
- Substantial time investment but compressed elapsed time
Primary use case
Complex problem solving where multiple perspectives add value; legacy-code rescue work; onboarding new team members; cross-training to eliminate knowledge silos; high-stakes work where quality matters more than speed; teams seeking deep alignment on coding patterns and decisions; specific phases of work rather than continuous mob practice.
Common criticisms
- Headcount cost is substantial — paying 5-7 people for the work of one is hard to justify economically except where the alternative (sequential work with handoffs and review delays) is also costly
- individual variation in mob-programming comfort is substantial and many engineers find the practice exhausting
- mob fatigue is real — full-day mobbing is rarely sustainable
- remote mobbing has matured (mob.sh, Visual Studio Live Share, others) but loses some embodied collaboration
- works less well for routine work that doesn't benefit from team perspective
- empirical evidence base is thinner than for pair programming
- can become avoidance of independent work that the team also needs
- some implementations are mobbing-everything dogma rather than mobbing-when-it-helps practice
- commercial certification ecosystem is small.
Lineage
- Child of
- Pair Programming
- Siblings
- Pair Programming, Code Review
- Derived from
- Pair Programming