Give software inspections a second chance

Raj Dhillon

Software Inspections Ronald A Radice Tata McGraw-Hill, 2003 Rs 525

‘Inspections’ (for benefit of the uninitiated) is a rigorous team review of a work product by peers of the producer for the purpose of finding defects.

Ronald A Radice, an early pioneer of software inspections, has drawn upon more than 30 years of experience to make a compelling case for the use of formal inspections in software projects. Radice provides enough data and experiential knowledge to prove that inspections are indeed a very cost-effective method for removing defects from software. It is 10 times more costly to find the same defect in testing and 100 times more if the customer finds it after implementation. Effectiveness of inspections in terms of percentage of defects removed by inspections over the total defects found is upwards of 50 percent and has been shown to go up as high as 90 percent.

So do we all use inspections? Flip through the operations manual of any software company in India and you are likely to find ‘Peer Reviews’ given pride of place as a key process for removing defects from software work products. You ask, "And how do we do peer reviews?" and your attention is likely to be directed to a guideline in the manual on Fagan Inspections. "And we do use Fagan Inspections here, don’t we?" you venture to ask. Odds are that you would get a long-winded answer, which after some reflection sounds more like a ‘No’ than a ‘Yes’. The reality is that even those who do use peer reviews are not getting the benefits of using the inspection methodology.

Why don’t we use inspections? The process of inspections is formal, rigorous and boring. Not as exciting as coding and testing. Software engineers do not like doing them. They’d rather spend all their spare time coding and then testing the code to find the defects than go through the rigour of inspections. The other villain is the manager—always in a hurry to meet deadlines and with a natural aversion to putting in effort up front.

Is there then a case to put in management time to resurrect inspections? For me the turning point came when Radice talks about ‘Education and increased knowledge sharing’ during inspections. A typical Indian software company operates with small teams—a couple of experienced developers and the rest recently inducted from another project, company or even campus. Now imagine them doing an inspection of a design document the way Radice says it ought to be done—as a group. I know one thing: At the end of the inspection meeting, they as a team would collectively know more about the design than they would ever have if the inspection did not take place. Now that sounds like knowledge management in action. In my view the inspection meeting is the building block of knowledge sharing in a software project. For me this is reason enough to give inspections a second chance.

Radice’s book is an invaluable resource on inspections. I strongly recommend that the Quality guys use it to enrich their operations manuals with procedures, check lists and implementation wisdom. I would also recommend it to every project manager as compulsory reading. They need to understand the possible benefits and pitfalls in taking short cuts in the name of meeting urgent deadlines. However, the challenge will be to get young engineers to use the methodology. Not an easy task in a country where taking risks and shortcuts is a way of life. Perhaps we could try to make the procedure a little less formal and boring—Oops! Here we go again with short cuts!

Raj Dhillon is head of quality at Zensar Technologies