4 ms·
If the change is extremely trivial then so is reviewing that change. Not much time is lost
by astonex 5y ago
If the change is extremely trivial then so is reviewing that change. Not much time is lost
- davidrupp 5y agoCounterpoint: The actual review of an "extremely trivial" change may not take much time (seconds), but it can take orders of magnitude more time (minutes to hours) to coordinate and execute that review (notify team of pending review, wait, ping team, wait, ping individual devs, wait, ...).
- munificent 5y agoI've spent the past decade working at a company that requires all changes to be reviewed no matter how trivial. Changes can be reviewed after the fact if the author marks it "to be reviewed". Doing that is rare, like <1% of changes. I have never found this policy to significantly hamper my overall productivity both as an author or as a reviewer.
- davidrupp 5y agoSo have I, except it's been three companies. One of them, ThoughtWorks, had built-in code review in the form of pair programming. I don't really have data on productivity, one way or the other, nor a strong opinion on the desirability or benefit of mandatory review. I was just addressing the specific comment of "Not much time is lost" above. Ç'est la guerre.
- drewcoo 5y agoIt's not about the time to review. It's about yet another interruption. For the sake of something trivial.
- alkonaut 5y agoIf it takes 5 seconds but happens after 10 minutes, then thee time from completing the development to review done is 10 minutes, not 5 seconds. That's the problem with review of trivial typo fixes. Obviously no org should have those reviews as somehow so mandatory that each individual developer can't override the policy such as by self-reviewing the change. If I was in an org where a policy required me to bug the dev next to me in order to approve a typo fix, I'd quite frankly quit.