Don’t do Code Review, try Mob instead
Code review disadvantages
- Long feedback loop
- Waiting
- Multiple unfinished tasks
- Written communication takes time, a lots of time
A typical day of programming meant for me “write code -> send to review”. What now? Eh… another task. The task was easy, let’s start a third one. Then urge the need for a review, then wait for a while, do a review by myself…
Finally — a review of the second task! No, I disagree, have to answer properly…. Another hour later I finish summarizing argumentation, and next day my colleague just answers OK. What? Just OK?!
The most significant problem of a code review is asynchronous ping-pong of quite difficult questions/answers. This is inefficient, but also makes people frustrated.
Another approach is to do code review as fast as possible. When I apply this approach, I end up doing code review all week long. And that’s not an exaggeration. The more code review I do, the more I receive requests for them. This leads again to frustration.
The goal of code review
What are benefits of a code review?
- Sharing knowledge
- Sharing responsibility
- Improving code structure
- Learning
A good code review covers all those aspects. But code review is just a tool, if we can find a better tool, we can throw code review away.
Mob programming
Mob programming means all team members are present in the same time in front of one screen. Or work remotely on a shared screen — that is my case.
I work in team of 4 people, and we work ~5–6 hours in day in the Mob style. At first we decide for the task, and when possible we rotate in driving sessions.
A session means there is a one driver — one who types/clicks, and one navigator — navigator tells the driver what to do. The 2 other team members keeps attention, and only when the navigator goes in a wrong direction, then interrupts. Navigator navigates for 3 minutes — really, just 3 minutes, and then rotate.
Rotation means that driver now navigates — should know next step, navigator takes a rest, and one of the 2 mobs drives. And after 3 minutes another rotation, and again, …
This rotation style is intense. You have to keep attention all the time, otherwise You’ll have to navigate in couple of minutes, and You’ll have no idea how to navigate.
To stay in shape we do regular breaks for bathroom/coffee, and of course a long break for a lunch.
Goals of code view are fulfilled
Sharing knowledge is instant — every team member follows the mental process, and knows why was what done.
Sharing responsibility in my opinion full — I take responsibility for everything that we produce as I can anytime say “I disagree” or “I have a better idea”.
Code structure is agreed by all team members, therefore is consistent and the best team members can do.
Learning… is again instant, and intense. If the navigator is good, they’ll not only call what to do, but also how to do it efficiently. I learn daily better software architecture, better testing strategies, how to use IDE efficiently, … just because navigators know (and share) pieces I’m missing.
All in all, Mob is in my opinion superior to code review in every aspect. And code review ping-pong frustration.
Mob must be inefficient
For first couple of weeks I thought that Mob is inefficient.
And that is definitely true when the team is settling or when team members aren’t yet experienced with languages and tools. In that period, Mob is extremely about learning.
But once the team passes these initial weeks, it becomes very different.
Almost everyday I experience a problem that would take me at least an hour (or hours) to solve when I would be alone. But there are 4 of us, and usually someone else have an idea how to solve it within minutes. My colleagues confirms that they experience the same — they have no idea what to do, and someone else knows it immediately.
Every team member is also better/expert in a different discipline. One is good in DBs, one in the framework we use, one is eg. good in decision making. So when the navigator is stuck, this one “expert” helps to overcome obstacles. And that happens instantly.
Mob requirements
Mob programming isn’t for everyone.
At first if You cannot be in the same time together (remote is ok), then it doesn’t work.
Mob requires good communication skills. There is no space for passive-aggressiveness; or arrogance. If You want to show You are better than Your colleagues, You aren’t a candidate for Mob.
Mob requires patience and respect — everyone isn’t always in the best shape and condition. If You like to rush solution, and You aren’t interested in leading/teaching colleagues, the Mob won’t work. Your colleagues won’t get better and the team won’t improve.
That’s all. If You can be in the same time (even remotely) together, You are patient, interested in new approaches, and Your colleagues have similar point of view, go for it. Mob is the way!
Mob vs Code Review
If I compare Mob vs code review, I have to laugh.
In code review style, I would struggle to solve an issue for hours, then I would send solution to code review, then I would wait, then the reviewer would suggest changes, I would argue for my solution or change the code. After 2–5 days I would have a code ready to be merged, but then I would have to solve merge conflicts!
There is no such thing in Mob programming.
- Struggle is limited by team members experiences
- No waiting
- Instant argumentation/code change
- Less merge conflicts
Mob has much more benefits, the most important for me is improving relation between me and my colleagues. Even programmers are social creatures, and Mob helps a lot.
I’d like to summarize that Mob programming dramatically shortens the feedback loop, and it has awesome consequences.
