Even though the benefits of inspection have been extensively documented, you may find it hard to introduce this practice into your development process. A novel approach to finding defects, an outsourced software inspection service is easier to introduce and has successfully jump-started inspection in the software development organizations of major telecommunications and industrial process companies.
While many articles do a great job of explaining the benefits of various ways to inspect software, relatively few address the issue of how to introduce software inspections into your development process. In practice, this turns out to be far from trivial.
Perhaps even more than other changes to the development process, attempts to introduce "traditional" inspections generally meet with a lot of resistance. Most objections are along the lines of "it's difficult," "it costs too much," or "we don't have time."
In this article, I will analyze objections to inspection using insights from diffusion research, explain how outsourced software inspection services work, and show how they can address many of the objections. The conclusion is that you can use an outsourced software inspection service to jump-start your organization into embracing the concept of inspection.
Causes of Resistance to Inspection
In Diffusion of Innovations , E. M. Rogers identifies five factors that characterize innovations:
- Relative advantage– the perceived advantages over the existing situation or other alternatives
- Compatibility–the degree to which it is felt that the innovation is consistent with the existing situation
- Complexity–the degree to which the innovation is difficult to understand
- Trialability–the degree to which an innovation can be tried
- Observability - the ease with which the benefits of an innovation can be observed, imagined, or described
Innovations that are perceived as having less complexity and greater relative advantage, compatibility, trialability, and observability will be adopted more rapidly. This model helps us to understand why inspection as a broad concept has met with such a slow adoption rate.
Let's investigate each of these factors in more detail by looking at the perceptions people hold relative to starting an inspection process.
1. Relative advantage. There is an impressive amount of literature (see An Encompassing Life-Cycle Centric Survey of Software Inspection by Oliver Laitenberger and Jean-Marc DeBaud for a very recent overview) reporting that inspections indeed offer an advantage, since they can remove up to 88 percent of all defects. No other defect detection technique has been shown to find more than half. But to understand the adoption of innovations, you need to look at the perceived advantage. In fact, many people don't see the benefits of inspection; all they see are what they perceive as disadvantages:
- Fear of being exposed. A fundamental element of most inspection techniques is to have your peers review your work products. Few people are comfortable with the idea of others finding defects in their code. While they will usually not dare to directly voice this fear, it might explain the vigor with which they raise some of the other objections.
- Fear of losing control. Most engineers have a strong need to be in control of their work. By showing their work to others, and accepting proposals for improvements, they are essentially granting others control over the way they do their work.
2. Compatibility. Inspections do not require new tools and equipment, and from a process point of view, they are independent of existing testing phases. However, they do have influence on the timing of all subsequent testing phases. This characteristic leads to the following objections:
- We have no time for this. This is a classic argument used against any kind of preparatory or preventive work: scheduling time for these activities moves out all remaining milestones, unless you're willing to believe you will earn back the investment later. Even if you believe you will make up for the time "lost" in inspection, you have to make adjustments to the initial parts of your development schedules, which will have an impact on the