Why Code Reviews are important ?

As a general rule, formal inspections are about twice as effective in finding bugs as any known form of testing. Most forms of testing are less than 30 percent efficient in finding bugs, but formal inspections on average are more than 60 percent efficient and sometimes top 95 percent. As an additional benefit, inspections also raise testing efficiency levels and they serve as surprisingly effective defect prevention methods.

The term inspection refers to a formal procedure in which a trained group of practitioners examine a software artifact, such as a specification, page by page in a planned fashion. Each inspection session is limited to a two-hour duration, and no more than two such sessions can be held in any business day. Prior to the inspection, each participant will have received the material to be inspected no less than a week prior to the start of the first inspection process.

It should be noted that informal reviews of another person’s work, which often occurs with the pair-programming concept, is not the same as a formal inspection. Informal reviews are useful, of course, but their measured level of defect-removal efficiency is usually less than 50 percent. Incidentally, the defect efficiency of programmers in finding errors in their own work is only about 30 percent. Most testing steps are also only about 30 percent efficient. Formal inspections have the highest average defect-removal efficiency levels of any form of defect removal yet studied.

The participants in the inspection process normally include the following set, although there is some flexibility and doubling up, such as having one person perform two roles

The producer of the material being inspected

A moderator, charged with keeping the inspection on track

A recorder, charged with keeping track of problems identified

A reader, charged with paraphrasing each section

One or more reviewers, charged with performing the inspection

One or more observers, normally novices there to learn how inspections operate

In really large organizations that use inspections, such as IBM or AT&T, there are other specialized personnel associated with the inspection process, too:

A coordinator, charged with scheduling inspections and reserving rooms

One or more trainers, charged with instructing novices in the inspection protocols

The minimum number of participants needed to actually perform a formal inspection is three: the producer, the moderator, and the recorder. In this minimum complement, the moderator and recorder are, of course, also serving as reviewers.

For an average inspection held within a major corporation on specifications associated with large systems, the normal complement is five personnel: the producer, the moderator, the recorder, and two reviewers.

The maximum number of participants in formal inspections is limited to no more than eight. This is a practical limitation caused by the fact that large meetings tend to be discursive and inefficient, coupled with the fact that rooms big enough to hold more than eight people are not readily available in many corporations.

The most difficult role to fill when performing inspections is that of the moderator, because the moderator must deal with rather delicate human relationship issues. It is sometimes stressful to have other individuals performing a close scrutiny of one’s work, and from time to time producers challenge the validity of whether or not a particular finding is really an error or defect or not. The moderator has to keep such disagreements from growing into full-scale disputes.

The reviewers also must be selected carefully, since they have to understand the work being inspected. For large projects, the reviewers are normally selected from the project team for the practical reason that other team members have the best prospect of being able to contribute meaningful observations.

On average, software designs and specifications contain about 1.25 errors or defects per function point, which for a project of 1000 function points can amount to about 1250 design bugs. Of these, about 15 percent, or almost 200, will be serious.

Design inspections average about 65 percent defect-removal efficiency overall, but against serious design defects the efficiency of formal design inspections tops 95 percent. Therefore, after a series of formal design inspections on this 1000–function point example, only about ten serious design issues may remain under best-case conditions.

By contrast, most forms of testing are less than 30 percent efficient in finding bugs, and are even less efficient in finding design defects. If design errors stay in the design, there is a strong chance that testing will not find them at all, because test cases are constructed using the design specifications as the basis. The efficiency of testing in finding design errors is less than 10 percent, which is a very low value indeed.

Surprisingly, formal inspections have proven both to benefit overall project costs and to shorten project schedules. Indeed, the inventor of the inspection process, Michael Fagan, received an IBM outstanding contribution award for determining that inspections shorten schedules as well as improve quality when applied to major systems software projects.

Although formal design and code inspections originated more than 35 years ago, they still are the top-ranked methodologies in terms of defect-removal efficiency. Further, inspections have a synergistic relationship with other forms of defect removal, such as testing, and also are quite successful as defect-prevention methods.

ormal inspections have not yet played a major role in the Agile methodologies. Extreme programming is interested in quality and is good in testing, but has not adopted formal inspections. The daily Scrum sessions that identify and discuss problems are useful, but they are not as efficient as formal inspections.

A combination of formal inspections, formal testing by test specialists, and a formal (and active) quality-assurance group are the methods that are most often associated with projects achieving a cumulative defect-removal efficiency higher than 99 percent.

Formal inspections are manual activities in which three to eight colleagues go over design specifications page by page, using a formal protocol. In order to term this activity an inspection, certain criteria must be met, including but not limited to the following:

• There must be adequate preparation time before each session.
• Effort expended during preparation and during the inspections is recorded.
• Records must be kept of the defects discovered.
• Defect data should not be used for appraisals or punitive purposes.

The original concept of inspections was based on actual meetings with live participants. The advent of effective online communications and tools for supporting remote inspections, now means that inspections can be performed electronically, which saves on travel costs for teams that are geographically dispersed.

Any software deliverable can be subject to a formal inspection, and the following deliverables have now developed enough empirical data to indicate that the inspection process is generally beneficial:

• Architecture inspections
• Requirements inspections
• Design inspections
• Database design inspections
• Quality Function Deployment (QFD) diagrams
• Code inspections
• Test plan inspections
• Test case inspections
• User documentation inspections
• Web page inspections

For every software artifact where formal inspections are used, they range from just under 60 percent to more than 90 percent in defect-removal efficiency and have an average efficiency level of roughly 65 percent. Overall, this is the best defect-removal efficiency level of any known form of error elimination.

Further, thanks to the flexibility of the human mind and its ability to handle inductive logic as well as deductive logic, inspections are also the most versatile form of defect removal and can be applied to essentially any software artifact. Indeed, inspections have even been applied recursively to themselves, in order to fine-tune the inspection process and eliminate bottlenecks and obstacles.

It is sometimes asked why everyone doesn’t use inspections if they are so good. The answer to this question reveals a basic weakness of the software industry. Inspections have been in the public domain for more than 35 years. Therefore, except for a few training companies, no company tries to >sell inspections, while there are many vendors selling testing tools. If you want to use inspections, you have to seek them out and adopt them.

Most software development organizations don’t actually do research or collect data on effective tools and technologies. They make their technology decisions, to a large degree, by listening to tool and methodology vendors and adopting those represented by the most persuasive sales personnel. Since there is comparatively little money to be made in selling inspections, sales personnel tend to concentrate on things like testing tools, where the commissions are greater.

It is even easier if the sales personnel make the tool or method sound like a “silver bullet” that will give miraculous results immediately upon deployment with little or no training, preparation, or additional effort. Since inspections are not sold by tool vendors and do require training and effort, they are not a glamorous technology. Hence, many software organizations don’t even know about inspections and have no idea of their versatility and effectiveness.

The companies that are most likely to use inspections are those that for historical or business reasons have some kind of research capability that looks for best practices and tries to adopt them.

It is a telling point that all of the top-gun quality software houses, and even industries, in the United States tend to utilize pretest inspections. For example, formal inspections are very common among computer manufacturers, telecommunication systems manufacturers, aerospace equipment manufacturers, defense systems manufacturers, medical instrument manufacturers, and systems software and operating systems developers. All of these need high-quality software to market their main products, and inspections top the list of effective defect-removal methods.

One of the most effective ways of illustrating the effectiveness of formal inspections is to produce graphs that connect the points where software defects are >discovered with the points in software development where the defects originate.

Whenever there is an acute angle in the line connecting a defect’s discovery and origin points, there is a serious problem with software quality control, because the gap between making an error and finding it can amount to many months.

Both in real life and in software cost estimating, the combination of having quality as a key project goal, keeping complexity low, and having experienced users and experienced team members pays off in lower costs, quicker schedules, and higher quality than result through the opposite situations.

Formal design and code inspections are fairly major discriminators between best-in-class organizations and the rest of the software industry. The really good groups tend to use inspections because nothing else can find so many bugs or errors, nor find so many deep and subtle problems, as the human mind.

References :

Estimating Design Inspections

by Caper Jon