Podcast: Play in new window | Download (45.1MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
Mob programming is a technique for getting multiple developers in the room, working on the same code. While possibly not the best technique for many situations, it really shines in certain narrow use cases. When it does work, it can often produce impressive results that a few separate developers couldn’t produce on their own. The collaborative aspects of mob programming are similar to pair programming in some respects, with very similar upsides and downsides.
In a mob programming session, a stakeholder and the team will first identify the goal of the session, which should be a testable outcome. Then everyone works together to come up with a general strategy and procedure for getting the work done, including what tools will be used to accomplish the work. This is a critical first step if you want to avoid stopping and rewriting code frequently while everyone else is watching.
Then, when the session begins everyone goes into a room and works together. One person will be typing for a while, while the rest of the team looks at the screen (or hopefully a projector) while the first person works. They will offer feedback as the first person does some work. The person writing the code will change frequently so that they don’t burn out. The rest of the team is there to support the first person as well as to offer feedback about various aspects of the code. In effect, this allows for the session to have the blessing of the entire team, and to incorporate the knowledge of the entire team. More tasks will probably be assigned to various team members as a result of the session as well.
Mob programming is a seldom-used, but often powerful approach to getting software written. While it’s not always the best choice, it can be very useful for improving team collaboration or for exploring areas where there are gaps in the team’s knowledge.