3 ms·
The up-front cost of code review can be easily be tripled or quadrupled when it’s distributed over several weeks after the fact in the form of unplanned work, e
by ljm 1y ago
The up-front cost of code review can be easily be tripled or quadrupled when it’s distributed over several weeks after the fact in the form of unplanned work, each instance of which incurs its own cost of context switching, as well as the cost of potential rework.
The purpose of such a review is a deliberate bottleneck in the earlier stage of development to stop it becoming a much larger bottleneck further down the line. Blocking one PR is a lot cheaper than blocking an entire release, and having a human in the loop there can ensure the change is in alignment in terms of architecture and engineering practices.
CI/CD isn’t the only way to do it but shifting left is generally beneficial even with the most archaic processes.
- monkeyelite 1y ago> The up-front cost of code review can be easily be tripled or quadrupled when it’s distributed over several weeks You’re taking a more extreme position than the one I’m stating. You can review every day or every hour if you want. > a deliberate bottleneck in the earlier stage Wouldn’t it be better if we could catch bugs AND avoid the bottleneck? That’s the vision. Good intentions may disagree about how to accomplish that.
- ljm 1y agoTo catch bugs and avoid the bottleneck that is code review, you’re just moving the bottleneck to some point after merging the code, not before. Like it or not you still have to stop what you’re doing to identify a bug and then fix it, which takes time away from planned feature work. You’re not optimising anything, you’re just adding fragility to the process. As I said before, an issue localised to a PR in review blocks one person. An issue that has spread to staging or prod blocks the entire team.