Code Review – How to get it right?

Code quality is one of the often talked about issue in a project status meeting. The magnitude of this issue will be bigger in case of maintenance products, where end users are encountering defects. While all the members of the project team very well know that code review if done well during the build phase could reduce the code quality issues by a significant percentage. The design and build process manual clearly calls it out that code review is an exit criteria for the code to move on to QA for testing. But still this issue surfaces every now and then.  

The question that comes up is whether code review was done at all or done just for the sake of process compliance. The possible reasons for reluctance among the developers to do a peer review are: Lack of reviewing skills, using the review finding against the developer for reviewer's personal advantage, inferiority complex of the developer. The other most common reason cited attributed by developers is lack of time. 

As all of us are very clear on the benefits that the code review bring on the table, let us not try to list out and discuss about the benefits. Let us attempt to list down the required skills of a code reviewer.

Subject matter (Domain) expertise:  Though most developers are not expected to be domain experts, this skill will certainly be required if the code review is expected to prevent functional defects getting slipped into the next phase. The very fact that the developers need not have domain expertise could possibly mean that the developer might have not understood the requirement as it was intended to be resulting in injection of defects. A mis-interpretation of the requirements could result in a functional defect and there is a chance to spot it if the reviewer posses the domain expertise. Some of the production defects could be unique and may not be reproducible and in such case, code review is the recourse to trouble shoot. This if done well during the build phase, could have prevented such defects surfacing in production at a later stage.

Technical Skills: The reviewer should be an expert in the technology and the programming language used. In software programming, code could be written in innumerable ways for a given requirement. However, given the standards and practices the team is expected to follow, the various quality attributes identified for the project and the goals set for the specific review, the reviewer should possess appropriate level of knowledge to spot problem areas. It is important for the reviewer to know the internal subsystems and the inter dependencies on various local and external computing resources.

Positive Attitude: This is a very important skill for the reviewer and the reviewer should never use the review findings against the developer as an individual. The issues should be considered as a team issue. The Reviewer should acknowledge the capabilities of the developer and the developer may have valid reasons for having written code in a particular way. At the end of the review, it would be a good idea to discuss the summary of the findings with the entire team, as some findings could be good learning for other team members. The organizational standards and practices should also be revisited and revised if necessary based on the nature of the findings. This may also result in identification of certain training needs for the team.

Team Skills: Both developer and the reviewer should have the common objective of producing quality code out of the build phase and they must work as a team to achieve best results. If not, the code review may happen just for name sake or may lead to personality issues which in turn would affect the project deliverable.

Attention to Details: This is an important skill a reviewer should possess to carry out effective reviews. Typically it is human to miss certain blocks of code as parts of it may appear to be correct. Unit testing is not a substitute for code review. The reviewer should with respect to each line of code, ask questions like, what if this statement fails to execute, if there is any other best way to achieve the same action, whether this could lead to potential performance issue, whether this statement may require more system resources, like Memory, CPU time, etc.

Knowledge on Tools: In addition to the above, code reviews with certain specific goals will require knowledge and expertise on appropriate debugging and diagnostic tools.

One of the key metrics in the Software Engineering space is defect injection ratio. This helps to identify the phase that has injected most number of defects. Many times, the stake holders think that it is the developers who inject defects into the delivered software. The reality however may not be completely true as much number of defects get injected in the requirements and design phase also. However, code review when rightly used, helps the development team not only to keep the defect injected in the build phase under control, but also not let the requirements / design phase defects slip into the next phase.