The code review process helps engineers double-check their work, keep the system extendable to new features, and understand what needs testing before the software released to the public.
Surely we don’t want to get rid of it.
But have you asked yourself - what it costs engineers, and can it be optimized?
What happens in detail
While we imagine code review as a quick, one-per-feature activity, a closer look at the process will reveal some details that extend its lifetime.
There is the idle time between passed review and QA. This time engineers switch context to something else.
In case of any questions or issues found during QA - engineers need time to change context back again.
Code review required to answer questions or pass additional changes back to QA.
Described above loop may repeat multiple times, even per small change.
Let’s assume empirically that code review takes 15-30-45 minutes of one engineer. To switch the context, we may count another 15-30-45 minutes. In case it’s repeated three times - we have 1.5-3-4.5 hours spent per one work item.
You may disagree on time values above, but doing a review, the engineer has to look at a ticket description, at the application itself, at code and only then - at diff in the pull request.
So, how many work items you have in your sprint backlog? 10? 15?
Depending on the application complexity, team size, and velocity - code review may take 40 man/hours in a month from engineers.
The other place where sort of code review happens is gathering release notes and signing approvals. For some reason, we don’t count this time at all.
You may take notes from closed tickets in your task tracker, yet tickets may not be appropriately updated, or engineers may include unplanned work.
What to do then? Right, look at the cumulative diff between the previous version and the upcoming one. Only once per release, it may take hours to get the needed information.
In case you have critical places to double-check - the number increases.
Public APIs, database schema updates, and deployment configuration changes are just examples of what may be crucial for the upper management - yet missed by engineers, who still focus on implementation rather than DevOps.
What Codeventory offers?
First of all, your development process may have no signs of the problem we have described here.
Codeventory started from problems observed during work for enterprise-level software products.
We also plan to do research involving diverse software engineers and companies to confirm the empirical values used in this article.
With our visualization and integration with ticket management systems, we target at least half less time needed to finish the review routine.
But more important - we want to change the experience.