Continuous code review
Continuous code review is the name I gave to a set of improvements to the typical code review process in one of the teams I worked with. One day, we faced a small bottleneck. On one hand, we had a large amount of work to do. On the other, we had new developers who needed some guidance due to the project technical complexity. We needed all hands on board, but those less experienced developers couldn’t efficiently contribute to the most important tasks due to… well… lack of experience. We could not afford mob programming, at the same time the typical code review process and training were not enough.
tl;dr;
Continuous Code Review is a daily meeting between team experts and the task author which lasts approximately 30 minutes. We discuss code increments from the last day, and provide feedback to capture the issues quicker than in the traditional code review.
Problem
Usually, hiring a developer is only the beginning of the road. To contribute efficiently, everyone has to gain experience, and master the project. Creating a space for learning is not easy. It requires both having several simpler tasks in the backlog that can be given to the newcomers, and time to provide feedback. Mob programming takes it to the extreme: the whole team works together on a single task, on a single machine. It reduces the capacity, but the feedback is nearly instant which starts paying off quickly.
In our case, there was no option to put everyone to work on a single thing. At the same time, we noticed that the typical code review is not enough. A challenging task can take 2 to even 5 times more time to complete for a newcomer than for an expert. It’s a lot of time to make wrong decisions, when left without feedback. Then, once the pull request finally arrives, others need to spend more time to read it and understand. Usually it ends up with a major rework… which requires even more time. The feedback loop is simply too long.
What is Continuous Code Review?
Continuous Code Review is a technique for discussing project increments which attacks the feedback loop problem. The goal is balancing the feedback needs and the availability of team experts. To do it, we need three things:
- a challenging task given to the less experienced developer (author),
- a 30-minute time slot every day in the morning,
- a team expert or experts available at that time every day.
The experts and the author meet every day for 30 minutes and walk together through the code written in the previous day. They discuss the following matters:
- design decisions,
- code quality and code style,
- looking for missed use cases.
The increment is usually small enough that 30 minutes is sufficient. The meeting can be lenghtened, but generally it shouldn’t last longer than 1 hour. The important thing is writing down all the noticed issues, and fixing them until the next meeting (unless agreed otherwise for a particular issue). We do it to avoid the cumulation of issues, and avoid building the next increment against known wrong assumptions.
We must also note that the Continuous Code Review does not eliminate the formal code review of the pull request at the end of the work. However, it greatly shortens it, because other team members are familiar with the code, and all the major issues should have been already resolved through the daily discussions.
In short…
In Continuous Code Review, the team discusses the code increments daily. Fixing the found issues immediately is critical. Also, it does not eliminate the final code review when the pull request is created.
Consequences of continuous code review
When we applied the Continuous Code Review for the first time, we noticed that it greatly reduced the amount of major reworks. Here are my conclusions why it happened:
- the team noticed wrong decisions early, when there was still little code to revert,
- we noticed additional use cases and things to think about early, and we could take them into account during later development.
- daily increments were very small, so it was easier to focus on details.
Obviously, this translated to fewer delays. In our case, we observed the following changes of time needed to complete a challenging task done by:
- … an expert: 1.5 – 2 weeks
- … a less experienced developer: 3 – 5 weeks
- … a less experienced developer with CCC: 2 – 2.5 weeks
Another consequence of applying CCC is related to learning. For large tasks, the typical code review produces many issues of different types. The pressure to fix them is also bigger, therefore it’s hard to focus on a single thing. It’s like learning for the university exam after not paying attention for the whole year: you gain a lot of knowledge in short time, you pass the exam (or not), and then everything quickly evaporates. Continuous Code Review aims to serve knowledge in smaller pieces, so that there’s more room to memorize it and use later.
In short…
The quicker you notice the issue, the cheaper it is to fix it. Learning under pressure is very inefficient.
Differences from mob or pair programming
Both mob and pair programming have some impact on the team capacity. In those styles, either a single expert or the whole team is designated to work on someone else’s task. It’s intentional, but not always affordable. The Continuous Code Review allows the team expert to work on his/her own task. The experts only need to reserve 30-60 minutes per day. It requires some context switching, but it is time-boxed and planned. In our team, we didn’t feel overhelmed with it. On the other hand in mob and pair programming, the expert is fully focused on a single task.
In mob and pair programming, less experienced developers work together with experts. They can watch how experts solve problems, and they can take challenges under their supervision. This is the strength of the two techniques, since it reduces the feedback loop to the absolute minimum. In Continuous Code Review, the feedback loop is short, but the less experienced developer has to figure out the solution to the issues on his/her own.
In short…
Mob and pair programming have much shorter feedback loops, and give the opportunity to watch how experts work. On the other hand, Continuous Code Review has minimal impact on team capacity.
When not to use Continuous Code Review?
To make Continuous Code Review work, we need some experts on board. Therefore, this technique is not suitable for early stages of the greenfield projects, and brand new teams, where everyone needs to gain experience and develop a common team style. Similarly, if you can afford mob or pair programming, go for it.
Summary
Continuous Code Review turned out to be a great tool that filled the gap between the classical code review, and pair/mob programming. When we applied it for the first time, the team quickly liked it, and later one of the standard questions when discussing user stories was “ok, do we need CCC for this task?” The good thing is that the majority of less experienced developers who really want to learn and have chance to work with experts, quickly ask for more. Sometimes, the need for extra feedback arises unexpectedly. Everyone has their tasks, but suddenly one of the devs needs some extra help. It’s much easier to arrange such ad-hoc CCC meetings than full pair programming sessions. However, personally I’m not restricted to CCC. When there’s time, we do pair programming.
