3 min read

Mob Programming is a programming paradigm that is an extension of Pair Programming. The difference is actually quite straightforward. If in Pair Programming engineers work in pairs, in Mob Programming the whole ‘mob’ of engineers works together. That mob might even include project managers and DevOps engineers. Like any good mob, it can get rowdy, but it can also get things done when you’re all focused on the same thing.

What is Mob programming?

The most common definition given to this approach by Woody Zuill (the self-proclaimed father of Mob programming) is as following:

“All the team members working on the same thing, at the same time, in the same space, and on the same computer.”

Here are the key principles of Mob Programming:

  • The team comes together in a meeting room with a set task due for the day. This group working together is called the mob.
  • The entire code is developed on a single system.
  • Only one member is allowed to operate the system. This means only the Driver can write the code or make any changes to the code.
  • The other members are called “Navigator” and the expert among them for the problem at hand guides the Driver to write the code.
  • Everyone keeps switching roles, meaning no one person will be at the system all the time.
  • The session ends with all the aspects of the task getting successfully completed.

The Mob Programming strategy

The success of mob programming depends on the collaborative nature of the developers coming together to form the Mob. A group of 5-6 members make a good mob. For a productive session, each member needs to be familiar with software development concepts like testing, design patterns, software development life cycle, among others.

A project manager can initiate the team to take the Mob programming approach in order to make the early stage of software development stress-free. Anyone stuck at a point in the problem will have Navigators who can bring in their expertise and keep the project development moving.

The advantages of Mob Programming

Mob programming might make you nervous about performing in a group. But the outcomes have shown that it tends to make work, stress free and almost error free since there are multiple opinions.

The ground rules to define Mob remains at a state where a single person cannot be on the keyboard, writing code longer than the other. This reduces the grunt work and provides the opportunity to switch to a different role in the mob. This trait really challenges and intrigues  individuals to contribute to the project by using their creativity.

Criticisms of Mob Programming

Mob programming is about cutting the communication barrier in the team. However, in situations when the dynamics of some members is different, the session can turn out to be just some active members dictating the terms for the task at hand.

Many developers out there are set in their own ways. When asked to work on a task/project at the same time, there might occur a conflict of interest. Some developers might not participate with their full capacity and this might lead the work being sub-standard.

To do Mob Programming well, you need a good mob

Mob programming is a modern approach to software development and comes with its own set of pros and cons. The productivity and fruitfulness of the approach lies in the credibility and dynamics of the members and not in the nature of the problem at hand. Hence the potential of this approach can be leveraged for solving difficult problems, given the best bunch of mobs to deal with it.

More on programming paradigms:


Subscribe to the weekly Packt Hub newsletter

* indicates required

1 COMMENT

  1. Funny. I wouldn’t even be worried about “performance in a group.” I’d be worried about several developers sitting in a room with me killing my productivity, as I needed to explain everything carefully instead of just coding it.

    For some particularly complex tasks, or for key architectural decisions, I could see using something like “mob programming” sparingly. But I’d be amazed if anyone could show four developers in a room together were actually more productive than four developers working separately, or even working as two pairs.

    I’m sure it’s fun. But I prefer to actually get things done.

LEAVE A REPLY

Please enter your comment!
Please enter your name here