Code inspections: reduce defects, increase understanding
When doing software maintenance on large systems, detecting defects is typically more complicated than when creating software from scratch: often it’s not possible to add useful safety nets such as unit-tests because of design choices in the existing system that make this impractical or because of size/time constraints with regards to the project. A useful technique is formal code inspections, not only because of its effectiveness in finding defects but also because it serves a purpose in program comprehension.
In What We Have Learned From Fighting Defects, Shull et al. document the results of several workshops in the area of defect reduction. One of their resulting statements is: Reviews catch more than half of a product’s defects regardless of the domain, level of maturity of the organization, or lifecycle phase during which they were applied. Which is quite a lot compared to other techniques (numbers from Code Complete 2, page 470) such as unit-testing (30%), regression testing (25%) and doing a full system test (40%). The only ones possibly scoring better are prototyping (65%) and high-volume beta tests (75%). The former however is impractical when doing maintenance and the latter takes much more effort than code inspections.
Formal code inspections have been in use for over thirty years. Michael Fagan published his paper Design and code inspections to reduce errors in program development in 1976, after having applied the techniques at IBM in the years before. While a very interesting read, the process description Fagan provides is a bit dated. A good alternative is A Guide to Code Inspections (PDF) by Jack Ganssle. It consists of a process description, some considerations and a form to use when doing inspections.
Now if this isn’t incentive enough to start doing inspections, consider the additional advantage during maintenance: as I wrote about before, reading code is about half the effort in software maintenance, which means it’s easily the biggest part (since implementing, testing, deploying, etc. is all in the other half). When you modify code and have it inspected by others, not only are you getting the typical defect reduction associated with inspections, the ones doing the inspections are also reading the modified code and acquiring knowledge about the system’s structure and functionality. Don’t make this an explicit goal however: the strength of inspections lies in the total focus on finding errors. Learning about the system is a built-in side effect.
Important to note however that this may still be useful if you already do pair programming. As Arie van Deursen notes in Program Comprehension Risks and Opportunities in Extreme Programming, the focus of pair programming (implementing functionality) is quite different from that of code inspections (finding and removing errors), so the idea of reviewing code all the time during pair programming, although useful, may not provide the same level of defect reduction compared to actually doing additional explicit code inspections.
