My experience with Mob Programming
One of the things I like the most about programming (or life in general) is that sometimes you get to discover new concepts that completely blow your mind and shift your point of view.
The last time it happened to me it was when, with my team at Datix, we tried out mob programming.
After watching a talk by Woody Zuill on mob programming, I was a bit perplexed but very interested. I wanted to try it out, but I knew that it was not going to happen if we had to try and convince managers to introduce it. So, one day, I picked up a projector, set it up in a communal area and invited my colleagues to join in.
Here I’m going to illustrate my personal takeaways from this experience.
What is Mob Programming
This article is about my personal takeaways rather than a description of what mob programming is. In a nutshell:
- One computer for the whole team, usually connected to a projector.
- The person at the keyboard (the driver) is not allowed to think. His only role is to translate the team ideas into code.
- Every now and then the driver changes seat with another member of a team. This can be timed.
👍 The good
No blockers
For some projects and some programmers, downtime is a big drain. Programmers are often blocked by missing requirements, unclear tickets, or big chunks of spaghetti code written by somebody else.
Mob programming reduces this a lot. If somebody else knows about the code or the issue involved, he will shed light. If requirements are not clear, a product owner should be involved in the mob to clarify the big picture. It’s a lot faster to understand each other when people are in the same place at the same time. Not so easy with the usual ping-pong of tickets between managers and programmers.
Waaay better code quality
It might be the wisdom of the crowd, swarm intelligence, or simply the fact that it’s difficult to sweep stuff under the rug when somebody is watching: the fact is that our team experienced 0 (Z-E-R-O) bugs in code being produced in the mob. The result is well designed and fully covered by unit tests. Code styling is also more consistent.
More productivity
This might sound counter-intuitive. How can a team be more productive, when everybody is doing the same thing at the same time?
Well, first of all this is not always the case. When somebody feels that he is not contributing to the mob, he is free to go.
In addition, a lot of time is usually wasted in miscommunication, lack of knowledge, code reviews, meetings, and so forth. Mob programming reduces all of these.
I can’t tell the right figures, but for some kind of tasks we experienced a tenfold increase in productivity.
Everybody get to learn from each-other
I should have probably put this before everything else. Mob programming leads to an incredibly fast spreading of knowledge. From advanced programming techniques to simple shortcuts and IDE tricks. From the apprentice to the most experienced veteran, everybody gets to learn and wear the white belt again.
No pull-requests, code reviews, standups, meeting
Everything happens in the same room, and everybody is involved already. No need for boring stand-ups when your brain is still starting-up. Plus, no more bitter corrections during code-reviews when it is often too late to fix the issues without doing some refactoring.
These are only some of the pros that come to mind. I’m sure there are more to come.
👎 The bad
Not everything should be done in the mob
We experienced that some tasks are better to be done outside of the mob. Some examples:
- Research: we couldn’t find a way to do it together. I personally need to be on my own to study something new. I had the feeling that it was the same for the rest of the team.
- Bug-fixing: We also experienced that fixing bugs is better done outside of the mob. In our case, it can involve big chunks of legacy code, and we didn’t notice such an improvement to justify an entire team on it.
It can lead to tension
The best thing about mob programming is that you get to learn how to be gentle and behave with people. It’s all about respect and humbleness.
Unfortunately, programmers are not the best folks at dealing with people, and they are often prima-donnas. A toxic member of the team can bring the whole team out-of-focus, leading to a big drain of energy. This should get better after the first couple of weeks. If it doesn’t, this might actually be a symptom of a problem you need to solve.
Wrapping it up
Mob programming is not a silver bullet, but for us it leads to a better environment and better software quality.
Try it out and see if it fits your team.
Any thought? Commenting is encouraged.
Thanks to Edson Medina and Francesco for proof-reading this.
If you want to hear more from my journey as a programmer, follow me here or on twitter.
