24.6. Explain why program inspections are an effective technique for discovering errors in a program. What types of errors are unlikely to be discovered through inspections?
Program inspections are the process of peer-review without testing. This is often line-by-line, and as such, has strengths and weaknesses when compared to a test-driven review process. The strength of this process is that reviewers themselves are programmers; thus, if they see a piece of code, and remember writing something similar (or different) to achieve the same functionality, then somebody will improve; either the reviewer sees something in the target code that they will learn and bring forward to their own projects, or they will see something that they deem problematic design because of their familiarity with that element of design, and will be able to suggest an improvement. Either way, the project wins. This is further strengthened by the fact that the original developer knows their code will be reviewed, so they will be incentivised to make their code readable wherever possible. This, again, ensure everyone wins.
However, there are many error types that do not synergize well with this technique. If code does not adhere to the style preferred by the reviewer, then they may have a difficult time parsing the code in their minds, and will likely complain about style but be unable to catch any errors beyond that; worse, their complaints about the style might force the original developer to redesign their code in a style they themselves are less familiar with, creating another realm of potential errors that must be caught and reviewed at a later date. Other errors which would be hard to catch would be ones which are simply hard to understand at all. If a target algorithm is sufficiently complicated, no amount of staring at it will allow a code reviewer to glean any meaningful insight into how (or if) it works correctly. These complex cases are far better suited to test-based scenarios, where one might statistically ‘prove’ the algorithm’s correctness, rather than simply stare at it and try to puzzle it out.
Due to the variety of methods in any large software, there is a guarantee that some will be better understood and improved by looking at them and imagining how they might go wrong; whereas others must simply be run to determine where they do go wrong. A balance of both approaches, therefore, is required for a truly robust quality management and review process.