From no code review to mob code review

One year ago, we had the opportunity to discuss with @__MaxS__ organizing the Software Crafts(wo)manship Nantes meetup about our engineering practices.

In this context, we presented a lightning talk about one of our emergent practices: the “mob review”. One year after, we’re still happy with this method, here is a short feedback.

During 4 years, from 3 to 20 devs in the core team, we continuously updated our workflow through retrospectives actions.

From no code review, passing by optional peer code review, to mandatory peer review with a minimum number of votes, we recently adopted the mob code review.

This practice is inspired by Mob Programming and aims to solve several communication issues we encountered by asynchronously commenting code on Github Pull Requests.

“Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.” (cf https://en.wikipedia.org/wiki/Mob_programming)

“Mob code review is a software development approach where the whole team reviews on the same thing, at the same time, in the same space, and at the same computer.”

These slides summarize our evolution regarding code review, the issues we encountered and the pros/cons of this practice.

As usual, there is no silver bullet, it may be useful (or not) in your own work context :)

I publish a couple of short stories per week; about product management, software engineering, and work organization. Don’t want to miss the next one? Follow me on Twitter 🐦