Code Reviews - The Pain and Gain

Typically, when implementation is done, code is modularized into chunks. Each chunk that does some small meaningful stuff and that does not break the build qualifies to be committed to version control. There is a school of thought that every commit has to be code reviewed. Now, while only the developer knows what he is upto and how the feature is getting implemented, the code reviewer in this context can only review to ensure that this new addition does not cause any harm. He is in no position to comment upon the completeness since it is assumed that more code has to be committed eventually before we are feature complete. If this is how we work, we have a case for a deep-dive session on every feature once its complete on top of the reviews that happen. Now, this deep-dive where design and implementation is discussed becomes the actual review session where completeness, correctness and consistency are debated upon. If this kind of session is missed, we can only expect that the builds may break the essential 3Cs (Completeness, Correctness, Consistency) and keep coming back as bugs.

The factors that could hamper this process could be:
• My team is not intelligent enough. It’s a waste of time.
• Doing this only to the manager or only when a manager is present. We are counting upon the technical skills of a person who prefers management over technology.
• As such there are too many meetings.
• Never mind, I am never wrong.
• Our testers will catch it anyway.
• This is not such an important feature.
• Well, I myself do not understand how I made this work.