If this is true, it misunderstands the primary goals of code review.

Code review should not be (primarily) about catching serious errors. If there are always a lot of errors, you can’t catch most of them with review. If there are few it’s not the best use of time.

The goal is to ensure the team is in sync on design, standards, etc. To train and educate Jr engineers, to spread understanding of the system. To bring more points of view to complex and important decisions.

These goals help you reduce the number of errors going into the review process, this should be the actual goal.

▲

rossdavidh 7 hours ago | parent [-]

As Deming once said in regard to manufacturing inspections: "Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product."

The fact that software is "soft" makes it seem like this doesn't apply, but it does, not least because of the fact that once you have gone down the wrong path with software design, it is very difficult to pull back and realize you need to go down an entirely different one.

	▲	lokar 4 hours ago \| parent [-]
		I agree, but it's worse. Even a "simple" coding error (so, no long term arch issues) is a problem, if the review that catches it does not educate the author. The analogy to manufacturing would be something like if the parts coming out a machine are all bad, just sending them to re-work is not a solution, you need to re-calibrate the machine.