Do You Inspect?

First of all, great article.

As with any process improvement effort or software adoption project, humans must deal with 'change.'

From a code inspection perspective, at Parasoft we call this aggregation of techniques Automated Defect Prevention, the fundamental barrier to adoption and success is a lack of management sponsorship and lack of training. Management sponsorship is somewhat obvious, yet the lack of training is not training on a tool nor training on a particular development language, it is training on both the businesses expectations and processes for inspection.

Developers and engineers need to understand why these practices and processes are in place and what the expected benefits from the activity. Inspection is not always about finding bugs. It can be about consistency, compliance and process integrity.

I'll also add here that automated process measurement to monitor adoption is key.

The gap we see with between the 35% adoption among embedded engineers and 10% among IT drives this point home. Embedded teams and management have a lot more riding on the quality of software than IT shops.

from Tom Gilb, co-author Software Inspections
and author of Competitive Engineering (2005)
I have developed an Agile version of Inspection wich solves some problems of conventional Inspections. I call it Agile Spec QC. it is described in my CE book (Simple Inspections) and in free papers and slides at Gilb.com such as
http://www.gilb.com/tiki-do...

All your claims about the benefit of inspections are confirmed by my experience, and I used to be a strong advocate. But no one I know uses inspection now, and I don't push for it in my teams. And all of your reasons for this lack of adoption are completely wrong. The notion that vendor marketing could change things is preposterous. For today's programmers, commercial vendors are the least credible source of info, and open source community rep and word-of-mouth is far more influential. One reason why today's programmers don't use inspection is because it's hard and it's not fun and the agile community influencers are telling them that easier paths are better. A funner, more sociable form proposed by agilists is pair programming. But even this (an absurdly weak form of inspection) is rarely used because it runs counter to deeply-engrained attitudes of programmers and managers. Acceptance Test-Driven Development -- another looser, funner, more sociable practice -- may be sufficiently effective at removing/preventing defects in requirements knowledge. The additional cost of inspecting downstream artifacts may actually be unprofitable, given the economics of Web era software systems.