Developers should be given the opportunity to explain their code to one another. Often, simply explaining the code exposes problems that could later lead to errors. When the group members discuss the code, their discussion needs to focus on important issues such as algorithms, object-oriented programming and class design.

However, many code reviews do not do this; most are dry, boring and mechanical, which is why many developers hate them. For code reviews to be effective, they need to be fun and create ideas. Very often, they deteriorate to focusing on enforcing coding standards. When this occurs, groups usually decide that code reviews are not valuable, drop them from their development process and lose the potential benefits that can stem from a correctly implemented review.

If you want a code review to be successful, you should ensure that it does not involve routine coding standards checking. Coding standards enforcement is a valuable way to prevent errors that affect application reliability, security and performance, and to improve code maintainability and reusability. However, coding standards can be enforced more quickly, accurately and objectively when automated tools are used to check compliance as the code is being developed. Code review time may be needed to discuss suppressions of reported rule violations in exceptional contexts, and/or to recommend coding-standard modifications and tool configuration changes.

Nightly builds

Another fundamental element in establishing code ownership is a process that I call nightly builds. A nightly build is a completely automated process that rebuilds the application overnight, every night, without any human intervention. At the same time each night, the build should check code out from the code repository, rebuild the application and run test suites. When the developers come in every morning, they should see a report that contains any failed test cases and be able to immediately assess project progress and quality. This enforces the self-regulating mechanism, because it helps the group benchmark itself and assess the quality of the code. It also helps expose problematic developers and encourage them to improve their skills.