I have been exposed and tried a lot of different forms of programming; solo, pair, small teams, big teams, remote teams, teams across companies and, the topic of this article, mob programming.
Mob programming is when an entire team is programming on a single computer – one keyboard, one mouse, 3-7 (or more?) people. A mob does not have to consist of only developers; a mob can consist of one designer, one product owner, and two web developers.
While I am a little provocative in my choice of title and implying that mob programming is bad – it is not the entire truth about how I feel. Mob programming can be great. For example in aforementioned mob setup during the design implementation of the layout and user journey in the frontend of a new feature.
In such a scenario; the designer can make quick tweaks to the design during development (and does not have to spend time on getting design files pixel perfect), the two web developers can solve CSS issues quicker than one could, and the product owner can make sure the customer journey is turning out as expected.
The idea that I find problematic is the idea of permanent mob programming with 3-7 people with similar skill sets.
Some tasks are not suited to mob programming
As developers, we are not only tasked with writing shiny new features. There is a lot of communication, debugging, refactoring, maybe some “manual” labour like configuring servers or writing documentation.
The most common argument that I've heard for doing the more menial tasks in a mob is that you probably are more likely to make mistakes during the “boring” work – and a mob is more likely to catch the mistakes than one individual.
This might be the case for some, but what I've found to usually happen is that one or two might be focused on the task, and others might let the mind wander. People thinking about what to eat for dinner next week do not catch subtle mistakes. At that point they could be working on something more productive which would be less mind numbing.
If you know a lot about mob programming you might be sitting there, red faced with anger thinking that if he only did true mob programming – with a rotating navigator and a driver then none of that would happen. Trust me, it happens anyway. Maybe not to you, dear individual, but maybe your team mates.
People converge
One of the arguments for mob programming is that you are never stuck – you are so many working on the same problem at the same time. All with different knowledge sets and different backgrounds, someone in the mob probably knows the solution.
That might be true during your first months together. But over time, the members of the mob will transfer a lot of their knowledge to each other. The different knowledge sets and backgrounds will become less and less different.
The knowledge transfer is a great thing, especially for the less experienced individuals (and the bus factor), but the total amount of knowledge and experience in the mob/team will remain almost the same. It will only grow by what happens on the mob computer. Not so great for the team in the long run.
It does not deliver on its promises
It is worth reiterating that I am talking about a mob consisting of people with similar skill sets that have been working in the same mob for several months of longer. Say 4 React developers with great javascript skills and average CSS knowledge.
Some promises that I have heard about mob programming that I do not think applies to these mobs are:
Fewer mistakes
This is highly dependant on the individuals, but what I found very common is that if some senior developer with a lot of respect makes a mistake – chances are it might not get caught. We are social creatures, and calling out someone who carries a lot of respect is hard. Your level of certainty about the mistake will have to be quite high.
Another factor that plays in is groupthink. It is not a positive term, and can become a real issue when you have worked together for a while. It essentially reduces critical evaluation of ideas. When you have managed to converge your mob into a cosy unit you possibly removed the benefit of fewer mistakes.
Work always continues
Mob programming is said to always continue, even when someone has to go to a meeting or is home sick. While this is often true (one exception is team/company-wide meetings), you are exposing the work to another fault of us humans: diffusion of responsibility. The gist of it is that in a group setting you are less likely to take action or responsibility yourself.
Say you side tracked to talking about travelling or something else non work-related. During that time you probably don't feel as bad as if you side tracked yourself, looking up private travel plans on company time. My guess is that the mob version also lasts longer as long as the surrounding environment allows it.
Another factor is that any break you need to take have a tendency to escalate to the entire mob. How long breaks people need and how far between they have to between is very individual. If the person with the loudest voice needs more and longer breaks than the average team member then the net output is lower than it could have been.
Communication is fast
You can communicate in the mob quite fast – as it is essentially an eternal meeting. That could be a great tool to avoid blocking questions to stake holders, but not so in the mob of similarly skilled developers.
The blocking communication between developers tend to be either architectural in nature, or in form of code reviews. In case of architecture discussions; I don't know about you, but those discussions do not happen every day for me. When they do happen, gathering around a whiteboard is usually not that hard.
Code reviews in mob programming are fast though, and I won't argue against that. However, I would argue that the effectiveness of the code review is reduced. That is because you all were part of the same train of thought that lead you to the solution. There might be a simpler way of solving the problem that someone with fresh pair of eyes would have found.
Mob programming can be a great tool, but is not a great default way to work. I think that any mob should be short lived to minimize group think.
I also feel that in order to gain the most value of the communication benefit, that they should contain people with different skill sets and different responsibilities. All of those skill sets need to be relevant to the development of the feature in progress. I've been in mobs with backend developers for pure frontend work.
I think that the early success of trying mob programming might lure some teams into committing to it long term. I think that decision can have a negative impact on your work without you even noticing.
If mob programming in the setup I have talked about works for you, great. Hopefully I helped you see some potential pitfalls which might occur in new teams though.
Top comments (1)
I was looking for mob programming experiences to see if my team was the only one struggling with this approach. We do 100% mobbing. Thank you !
We see the same issues and benefits. I would like to add that mobbing is a catalyst for conflicts and even though the average code quality will go up, it is far from “the best of everyone’s ” that is often advertised. The productivity of the mob will also be constrained by slowest member of your team (slowest dev, slowest qa...).