3 ms·

Code reviews are very bad at finding bugs; that is not their purpose. Code reviews are great for finding design problems, identifying weaknesses in colleagues

by RogerL 12y ago

Code reviews are very bad at finding bugs; that is not their purpose. Code reviews are great for finding design problems, identifying weaknesses in colleagues (so you can help them increase their skills), keeping everyone knowledgeable about what is going on in other parts of the stack, cross-training, keeping the code readable and maintainable (if I can't easily&quickly code review your code, it is probably going to be a black box to everyone in 6 months) and so on. Not that they don't find bugs, they do. Just that is far from the primary value or the best way to find bugs.

sheepmullet 12y ago
My point is that there are plenty of other quality control techniques that may be better suited to your project and team. E.g. "Code reviews are great for finding design problems" Assuming you are talking code design problems: So are formal reviews, peer programming, or having multiple developers work on the same parts of the codebase. "identifying weaknesses in colleagues (so you can help them increase their skills)" Peer programming is great at this too, as is having a technical chat over a coffee, as is providing 20% time, as is regular technical training, as is allowing your devs time for their own l&d, as is having programmers work on the same parts of the codebase, etc, etc. "keeping everyone knowledgeable about what is going on in other parts of the stack" Technical walkthroughs, more consistent abstractions, and/or better doco are also great methods. Code reviews and unit testing hold this high status place in our profession to the point where most other quality control techniques have been thrown out the window. At my last company the single most effective policy for quality control we had was: Sleep on it (unless it was an emergency production fix - in which case we don't care about quality).

by RogerL 12y ago

sheepmullet 12y ago

My point is that there are plenty of other quality control techniques that may be better suited to your project and team. E.g. "Code reviews are great for finding design problems" Assuming you are talking code design problems: So are formal reviews, peer programming, or having multiple developers work on the same parts of the codebase. "identifying weaknesses in colleagues (so you can help them increase their skills)" Peer programming is great at this too, as is having a technical chat over a coffee, as is providing 20% time, as is regular technical training, as is allowing your devs time for their own l&d, as is having programmers work on the same parts of the codebase, etc, etc. "keeping everyone knowledgeable about what is going on in other parts of the stack" Technical walkthroughs, more consistent abstractions, and/or better doco are also great methods. Code reviews and unit testing hold this high status place in our profession to the point where most other quality control techniques have been thrown out the window. At my last company the single most effective policy for quality control we had was: Sleep on it (unless it was an emergency production fix - in which case we don't care about quality).