Code review is a first line of defense in defensive programming. Proofread a business document or personal letter that you have written, and then have someone else proofread the same document. The other person will almost assuredly find more problems than you. Why? At a subconscious level, you read what you think was written, which is often different than the actual text. Developers have the same challenge when examining code. It is difficult for them to see errors in their own code.

Some time ago, I was employed at the National Climate Center in Asheville, North Carolina, which is part of the National Oceanic Atmospheric Administration (NOAA). NOAA is a unit of the U.S. Department of Commerce. My manager asked that I write an inventory system. At that time, they had a Univac 1100/60 mainframe. Okay, maybe this was more than some time ago. I decided to write the inventory system as an online application—even though the customer had not requested this. However, it was cool! Unbeknownst to management, I ordered the technical manuals for the computer terminals. Using a combination of COBOL, FORTRAN, and assembler routines, I eventually completed the online inventory system. A few months later, I left the National Climate Center without documenting the application. Yes, I should have been drawn and quartered.

A couple years later, the National Climate Center bought replacement terminals for the old units. The new terminals were from a different vendor. Shortly thereafter the online inventory system crashed. For a small fee, I was coerced into returning to resolve the problem. I made the appropriate changes (basically rewriting the entire application) to correct the problem. In the meantime, they had hired someone to comment other people’s code. I was obligated to review the code—line by line—with this individual. This was a precursor to what is now called a code review. During the review, numerous problems were uncovered. Because of the code review, the final version of the application was much more stable and correct.

Have a formal process of code reviews at a minimum of two milestones: checking source into source control and product deployment. Informally, have a code review as often as reasonably possible. For informal code reviews, find someone outside your immediate team—someone who has a different perspective and maybe different assumptions. This will provide a fresh set of eyes on the code.