Mob Code Review
Intro
A few years ago, I was thinking about the idea of mob programming and how there must be an equivalent for code review. I then thought this was such an obvious idea that someone must have thought of it before. After a few minutes of searching, I found a blog post from Akeneo Labs that linked to some slides describing their practice.
I found myself nodding along with the pain points they identified as common in bigger asynchronous code reviews (in a GitHub PR, for example):
- Some PRs can turn into a sprawling mess of comments
- Review comments don’t always focus on what’s important and instead seem to prioritize the least important parts
- It’s easier to misunderstand each other when relying on written comments
The solution? Mob code reviews. Get people together in a room (or these days, a video call) and have a discussion about the PR. Make sure everyone understands the purpose of the review and focus on the important points together.
What We Tried
The version of mob code review that I tried was a little different from the one described in Akeneo’s post. I was feeling like we had quite a bit of specialization on our team and many people had stuck to particular areas of the code. When it came time for them to work on something else, they weren’t as confident in the new areas because they had little experience with those parts of the code.
After reading Akeneo’s post and slides, I decided to try using their approach for a non-PR code review where we just read through the code of a particular service together. I gathered people in a meeting room and we went exploring for about 90 minutes. Time-boxing the session meant that we were motivated to keep moving and not spend a lot of time in any one area. Anything important would be worth spending some time talking about, but superfluous details would be mostly ignored.
After the first time I tried running one of these sessions, I got really positive feedback from the team. I think some reasons that people liked the experience were:
- It gave them the opportunity to learn from others on the team without feeling like their questions were burdensome
- It strengthened their understanding of our services and how they worked together, helping to fill in gaps that they just hadn’t had the opportunity to work on yet
- They got the opportunity to discuss important aspects of the code and how things should be, rather than feeling the need to nitpick just to feel like they wrote something
I started at the entry point of the code I selected for the session and we spiraled out from there, following whatever threads of discussion seemed interesting. We had some discussions about why certain aspects of the code were done the way they were, how they were done at all, and whether they were done well. These are all great topics for a code review! We took notes as we continued through the session and identified a few work items to go and refactor parts of the code that seemed like they could be improved.
Tips
Some suggestions if you’d like to try this version of a mob code review with your own team:
- Select a facilitator to “drive” around in the code. Ideally, have them use their typical IDE so that they can jump around and follow references quickly. This person doesn’t necessarily need to be familiar with the code that is being reviewed, but I think it may go more smoothly with a more experienced developer who is able to quickly interpret what they are seeing.
- Select a designated note-taker (other than the facilitator) who can record any decisions or outstanding questions. We used these notes after our session to create work items for investigating or fixing things we had found.
- Time-box your session and keep it short enough that people will be able to remain focused. I generally try to have these sessions last 60–90 minutes.