Over the past 20 years, I've worked in many different development
environments. From IBM mainframes, Digital VAX, and Data General midrange
systems to Windows-based PCs, I've reviewed and approved the output of hours of
hard work by those around me.
My reviews include code for business systems, clinical information systems,
administrative applications, systems services, software and hardware drivers,
Web pages, and many other types of programs. The one underlying truth that
consistently appears is that all coding efforts run a high risk for defects or
standards-compliance violation. These defects could cost billions in
reengineering efforts if they make their way into production software. Add to
this the liability costs associated with defective software in critical systems
such as banking or healthcare applications.
Formalised code reviews can uncover these shortcomings before the code
achieves production status. The goals of code reviews are as diverse as the
environments in which they're created. However, almost all code reviews have the
following objectives in common:
* Quality, defect-free software
* Systems that are appropriate and
complete meeting requirements
* Software that complies with enterprise
In addition, many organisations add documentation and supportability to the
list. The downside to this list is that it provides no information on how to
achieve these goals. For example, quality, defect-free software is a noble
objective, but achieving it could take a Herculean effort on the part of the
developer and reviewer. Instead, organisations develop coding standards for
software development in an effort to pursue these goals. These standards usually
address issues of software commonality, performance, supportability, and
The organisation's development or architecture group usually creates software
development standards. The standards should address code at all levels to be
successful. This includes presentation, business logic, and data layers. Failure
to address software at all layers opens the opportunity for the unreviewed layer
to undermine the entire effort.
Standards should also be well documented. This means documentation must be
complete, precise, and disseminated to all developers in the enterprise.
Successful implementation of standards requires the reviewer to have the
authority to reject or disallow proposed software to achieve production status
based on the review. This authority should be universal and applied equally in
Knowledgeable personnel who are fully versed in the platform technology and
organisations standards should perform code reviews. For best results, the
review shouldn't be from the same project or development team. In fact, many
organisations identify "specialists" that are attached to a separate management
structure to conduct the reviews.
The reviewer's job isn't simply to say "yes" or "no" to proposed software.
The code reviewer should identify specific lines of code that are noncompliant
or in error. Then, formally document this information and return it to the
development team submitting the proposed software.
Finally, periodically review the actual coding standards for applicability to
the organisation's environment. This is especially important when fundamental
changes occur, such as upgrading operating systems or implementing new database