Mob Programming 101 - a case study

“Mob Programming is when three or more people work at a single computer to solve a problem together. It is about leveraging distributed knowledge when programming” (“Code with the Wisdom of the Crowd”, Mark Pearl)

Context

A few months ago, we started working on a new feature. Some loosely similar functionality already existed in our legacy system. Our task was to create it anew with different workflows in our greenfield project.

To implement the feature, we used Domain-Driven Design (DDD) in combination with Behavior-Driven Development (BDD). To facilitate this approach, we decided to use mob programming.

We wanted to test mob programming and find out the answers to the following questions:

• Is mob programming an efficient way of programming?
• What are its advantages?
• Is mob programming better than programming solo or pair programming?
• When is it useful? Should we use it all the time, only in certain situations or never?

Mob Programming

After a few meetings with business experts (in the form of Event Storming) we had some understanding of new functionality. We (5 developers) reserved a conference room, and our adventure with mob programming started. We had one laptop connected to the TV and a flip chart to write on. Only one of us — called the typist — was allowed to use the computer. This role shifted to the next person using the algorithm adapted from “ping pong pair-programming”.

Ping Pong Pair-Programming

The first time I’ve read about ping pong pair-programming was in a great book “Working Effectively with Unit Tests” by Jay Fields. He introduced it in the context of Test-Driven Development (TDD):

“1. A writes a new test and sees that it fails.
2. B implements the code needed to pass the test.
3. B writes the next test and sees that it fails.
4. A implements the code needed to pass the test.
And so on.”

We modified it to serve five developers in a kind of carousel:

• 1st developer wrote a test
• 2nd person implemented the code and wrote the next test
• The step above was repeated indefinitely by the next developers: 3d, 4th, 5th, 1st, …

This algorithm worked like a charm. It kept a high level of engagement of every developer and not only was it fun, but it also improved code quality due to constant review of the whole team.

If you don’t use TDD, just set the timer to 10 minutes for each interval. When the time is up, change the typist.

The Typist

According to Mark Pearl:

“The typist is not the programmer; instead, think of the typist as a smart assistant, taking what the rest of the mob is asking them to do and implementing it” (“Code with the Wisdom of the Crowd”, emphasis added)

Our experience with mob programming wasn’t without mistakes. One of the things we did unorthodoxly was how we treated the typist role. What we did was more or less the opposite of what Mark Pearl suggested. In our case, we implemented the typist’s idea. The typist was also the one who finally decided what to write. The rest of the team didn’t passively stand during that time, though. We argued, often very vividly, and proposed our ideas for a solution.

Our team consists of developers who are eager to express themselves and implement their ideas in the code, so it worked quite well. Next time, however, we will try to follow Mark Pearl’s advice.

Push Toward Getting To Code

Our work went most of the time smoothly, but sometimes we stopped to discuss some subjects that we disagreed on. Those discussions could take a very long time. During our retrospective, we agreed to change it and always push toward getting to code. This modification should shorten theoretical discussions and allow us to check ideas in practice quickly.

Tips & Tricks

Apart from the already mentioned, many other techniques may help you to make the transition to mob programming smooth. I will shortly discuss the two of them.

The Batman

In our company, we have feature teams. It decreases the coupling of our development areas. It also makes the work more efficient by minimizing the amount of cross-communication between different teams required to build a feature. Having said that, even in such a situation, it is sometimes necessary to discuss an issue with others or just help them with something.

While mob programming, our team needs to avoid distractions. On the other hand, we also want to cooperate with others and support them with our knowledge when necessary. It can easily become one of the extremes: on the one hand, the group can choose to hide in the closed room to avoid distractions. On the other hand, the team can be open and helpful, and as a result, be distracted all the time with a negative impact on productivity. Fortunately, there is a technique that helps to solve this dilemma. It is called “the batman”.

The batman is a role assigned to one of the participants of mob programming. Its goal is to protect the group from disruptions. Whenever someone outside the mob comes and have any questions or need related to the team, the batman is the only person that deals with it. The batman answers the questions or sets up a meeting for later. Thanks to that the mob is not distracted. The downside is that this person can’t take the typist role.

Micro Commits

Another useful technique is called “micro commits”. Whenever the typist is about to be changed, make a quick commit to your feature branch. Don’t bother with writing any long, meaningful message. Only when you finish the whole task or mob programming session, you squash (in git) those commits and create an appropriate message.

The advantage of this practice is that you are very agile. Instead of endless discussions, you can test an idea in your code. Then even if you spend a few intervals and it turns out to be wrong, you can quickly go back to any stage of your work.

The Outcome

We consider our experiment with mob programming very successful. During the development of previous features, sometimes one of us was an expert in some part of the functionality (e.g. legacy database schema or Elasticsearch). When our team had to introduce a breaking change in this part, we preferred to wait for our expert to come back from vacation. In the feature which we implemented using mob programming, we are not blocked anymore. We don’t need to wait for anyone to come back from vacation, because we all know our domain in detail.

Thanks to mob programming, the introduction of BDD in our team went smoothly, and the knowledge of this approach was spread among us evenly. To propagate this knowledge even further, we organized an internal knowledge sharing session about BDD inside our company. Then we also shared our experience in a workshop for developers outside EcoVadis.

After a few days of mob programming, we decided that it fulfilled its role and we switched to pair programming.

Since then, the new feature has been a few months on production and there hasn’t been even one bug reported. Our code coverage is above 90% for domain logic and slightly below that in other parts of the application. We believe it is partially thanks to mob programming and partly because of using BDD.

Conclusion

We recommend using mob programming during your first days of developing a completely new feature. Remember that before you start, you should already have some knowledge about the domain (e.g. from Event Storming).

We also recommend practicing mob programming when you want to introduce a new development process (in our case BDD). In this case, prior knowledge about the process is also crucial. Without it, you will have to break a meeting often to learn, experiment or find some information on the Internet.

After a few days of mob programming, you will start to feel that all of you understand the domain or the development approach. We think it is a sign to split into pairs. Pair programming still brings many benefits associated with a collaborative way of software development. What is more, it doesn’t involve the whole team in one job.

Finally, you will also encounter tasks that require a lot of investigation or just the opposite — assignments that are quite mundane. In those cases, we believe it is best to program solo.

Give mob programming a try. Remember to push toward getting to code. Experiment with ping pong way of programming. And finally, keep in mind the responsibilities of the typist.

The subject of mob programming is quite broad. If you want to explore this topic further, I recommend already mentioned book: “Code with the Wisdom of the Crowd” by Mark Pearl.