I was on a team of competent people working on a dense code base before and after introduction of gatekeeping code reviews. The code base was large so no two people would be working in the same area. Before code reviews:
- Team members working on a section of code would find and fix bugs in it.
- Team members would watch the repository history to monitor for any mistakes.
When gatekeeping reviews were introduced, they were not particularly effective at finding bugs because bugs tended to be subtle and required time working on the particular code in question to identify. But the introduction of gatekeeping code review caused bugs because:
- Once reviewed, code was assumed to be good enough because hey, two people agreed on it.
- Any bugs identified would require code reviews to fix which would be an uphill battle and probably involve project management.
- Nobody's looking that closely at history because who wants to deal with finding problems and pushing through fixes? And hey, it's already reviewed.
- Knowledge of code that is being reviewed becomes stale as you start working on other features. This impacts pre-commit testing as you make changes to mollify the reviewer, and thus lead to a bug.
- Lowering velocity lowers the rate of fixing bugs.
- A bug could be fixed but stuck in review, so it's still in the codebase for other developers to run across. You could argue: well, it's documented in JIRA! But bugs can manifest in different ways and affect multiple system.
I was on a team of competent people working on a dense code base before and after introduction of gatekeeping code reviews. The code base was large so no two people would be working in the same area. Before code reviews:
- Team members working on a section of code would find and fix bugs in it.
- Team members would watch the repository history to monitor for any mistakes.
When gatekeeping reviews were introduced, they were not particularly effective at finding bugs because bugs tended to be subtle and required time working on the particular code in question to identify. But the introduction of gatekeeping code review caused bugs because:
- Once reviewed, code was assumed to be good enough because hey, two people agreed on it.
- Any bugs identified would require code reviews to fix which would be an uphill battle and probably involve project management.
- Nobody's looking that closely at history because who wants to deal with finding problems and pushing through fixes? And hey, it's already reviewed.
- Knowledge of code that is being reviewed becomes stale as you start working on other features. This impacts pre-commit testing as you make changes to mollify the reviewer, and thus lead to a bug.
- Lowering velocity lowers the rate of fixing bugs.
- A bug could be fixed but stuck in review, so it's still in the codebase for other developers to run across. You could argue: well, it's documented in JIRA! But bugs can manifest in different ways and affect multiple system.