Mob programming, or mobbing, brings more than two people together to solve a problem in a shared work context. Participants may gather around one workstation or use an online collaborative IDE. As in pair programming, a driver focuses on the code while navigators provide direction; timed rotation is common, and the whole mob can help when someone gets stuck. section 12.0
Mobbing is strongest when a difficult problem benefits from varied perspectives, domain knowledge, and immediate discussion. It spreads institutional knowledge in real time: participants observe one another’s approaches, keyboard habits, searches, and ways of getting unstuck. Unlike asynchronous code review, questions and alternatives can be explored and tested immediately. section 12.1.1 section 12.3
Combine mob programming with code reviews rather than treating either practice as a replacement for the other:
- Agree and then split: use the mob to settle high-level goals, designs, or implementation direction, then divide individual work and review it normally. section 12.2.1
- Into the void: use the mob when the entire team is unfamiliar with the problem and needs to discover a path together. section 12.3
- Capture and chronicle: make mobbing the default working mode, then use a lightweight review to record context, decisions, and rejected alternatives. section 12.3 section 12.2.1
- Mob code review: gather the team to inspect a large or critical pull request, especially when individual review would be too burdensome. section 8.3 section 12.3
A shared architecture decision
A team considering how to break apart a monolithic application uses several mob sessions before implementation. Conversation reveals that “breaking apart the monolith” means microservices to one person, independent build and deployment boundaries to another, and internal refactoring to a third. Resolving those meanings together prevents the team from splitting into work based on incompatible assumptions; the resulting individual changes can still receive code reviews. section 12.2.1
Mobbing has limits. Too many navigators can silence participation and make discussion inefficient; passive attendees and frequent distractions are warning signs. Planned breaks help restore focus. The practice also depends on communication skills, psychological safety, respect for dissent, and willingness to consider others’ opinions. Without individual review, groupthink may hide errors and no durable record preserves the rationale for future teammates. section 12.2.2 section 12.1.3
Figure 12.1 Comparing code reviews, pair programming, and mob programming
Compare mob programming with pair programming and code reviews to see their shared quality and knowledge-transfer goals and their different roles. section 12.1
