The views expressed here are mine alone and do not reflect the view of my employer.
Pair and Mob Programming
Pair programming: When two developers sit at the same computer and work together.
Mob programming: When many developers(more than two) sit at the same computer and work together.
Pair/Mob programming Pros and Cons
The pros and cons are very similar between pair and mob programming. In other words regardless of if there are two, three or four devs the idea is the same.
Management may view pair programming as a misuse of resources, since they could have two devs pushing out code in parallel. This is mostly a misconception and the pros we are about to go through clearly explain why. But there are so me cons which teams need to manage correctly to make pair/mob programming work properly.
- Less bugs: Since many devs are thinking about the problem, the chances of bugs slipping through are reduced. Reduced bugs means a more stable system and less time debugging issues.
- Superior design: Multiple devs bring different perspectives and experience to the problems at hand. By having a diverse range of solutions the devs consider many options, instead of just using the first solution which comes to mind when deving solo. A superior design has improved maintainablity which reduces future dev time.
- Code review not required: Code reviews are famously useless, as many devs skim through it or take long to do it. In pair/mob progamming the code review is constanlty happening and corrected immediatly... saving time.
- Team members can not slack: When a dev is assign a task to work solo, it is very easy to get distracted or overinflate the complexity of the problem to get more time to complete it. When there is more than one dev, they are all kept in check by each other. This increases productivity.
- Shared knowledge and upskilling: By mixing experts in an area with non-experts knowledge can easily be shared. This reduces single man dependencies where one dev can hold a company randsome because nobody else knows what he knows. Due to the shared knowledge, planning and communication improve ten fold because the whole team is on the same page about the code.
- Adaption required: Not every task is equal and the pair/mob needs to change accordingly eg Having 6 senior devs working on a simple problem is a waste. (so you cant have a blanket rule that every task gets tackled the same way)
- Team members can disengage/slack: It is easy for one dev to keep saying they don't understand and just sit in the mob, and over time never add any value to the team. Having a slacker in a mob is better than a solo slacker since it is much easier to monitor them. This is firstly a hiring problem, but if you are stuck in this situation you can manage this by: 1. trying to motivate them, 2. placing them with the correct partners and 3. try calling out the offender and possibly revert that person to solo dev only.
- Not eveyone likes to work this way: I find that very few people don't like working this way even when they initially disagree with it. If your team is new to this then do short stints here and there, and let them take control most of the time so they slowly get used to it.
- Conflicts: Some diversity of thought is a good thing but when devs have vastly differently outlooks on the fundamentals then it becomes difficult to find a resolution to the conflict. Firstly, this is a hiring issue, otherwise mitigate this by agreeing upon fundamentals and style before hand as much as possible, but don't worry if conflict still arises because as conflicts are resolved the team will start to find a groove and work smoother. If the conflicts are too much then I prefer seperating some devs.
My team fluidly interchanges between pair, mob and solo dev as circumstances change. For example a day would like this: three devs will start working on a complex task while another starts on a simple task. When the simple task is done that dev will join the group on the complex task. Then maybe a production issue arises and two devs break off the group to look at the issue.
My team will take certain considerations into account before deciding on a mob to tackle a given task.
- Expertise: Do we have someone with the correct expertise for the task? Does anybody want to skill up in that particular area and learn from the expert?
- Task difficulty: How complex is the task? Do we need more heads together on this problem?
- Task importance: How important is the task? Is failure/bugs acceptable?
- Dev saturation: Are there too many devs already involved? At what point is adding more devs not going to be beneficial? eg 30 devs at one computer is redundant, since a handful of devs will be just as efficient.
Often you will hear people give very specific instructions on how to pair/mob programme as if there is only one way to do it. There are actually many different ways you can pair/mob programme. I recommend to try different techniques and change it up from time to time. I use all of the below techiques depending on the situation:Standard pair/mob programming
Method: one person codes and the others watch and make suggestions.
When to use: I use this for complex solutions which require deep consideration.
Reason: The person coding can complete large chunks of work while the rest of the team can comment when they think of edge cases to consider or see issues in the code. If the person coding does not know what to do or is junior then others must explain exactly what to type so that he can learn and still be actively involved in the process.collapse
- One person uses the keyboard and another person uses the mouse. This is an exercise in coordination and team work.
- One person types(only what he is told) and the others explain what to type. This is an exercise in communication for the person explaining.