What if you could double the efficiency of your software testing process, and substantially reduce errors found during the test, deployment, and maintenance phases, without purchasing any tool or method? The November 28 InformationWeek offers just that in a reprint of a recent Dr. Dobbs article on formal inspections by Capers Jones and Olivier Bonsignour. They call formal inspections the "defect removal tool of choice" and back up their claim with lots of hard evidence, but I think they are still selling short.

Formal inspections are closely structured, moderated reviews of code, design, requirements, or any other project artifact. There are specific common sense things a formal inspection must include, like real-time participation, adequate prep by participants, good note taking, and "not using defect data for appraisals or punitive purposes."

The authors present an impressive case. They contend that "most forms of testing are less than 30% efficient in finding errors and bugs. Formal inspections, on the other hand, have … an average efficiency level of roughly 65%." "Projects with inspections are about 15% more productive during development than similar uninspected projects, and their maintenance costs are about 45% lower."

Even so, only 17 percent of enterprises studied practice formal inspections, with adoption more prevalent among companies with high costs of poor software quality, like "computer, telecom, aerospace, defense, and medical instrument manufacturers." The authors attribute resistance to two things: (1) formal inspections aren't pushed by vendors and (2) inspections seem to slow down development (even though, Jones and Bonsignour note, "once testing starts inspections will dramatically reduce testing costs and speed up the schedule.")

I've had experience with walkthroughs and inspections of varying degrees of formality, and my experience squares with the authors' claims. However, I think their measured and factual approach downplays the most significant benefits: architectural compliance and teambuilding.

Application development projects today often feature bare-bones, geographically dispersed teams working at breakneck speed to meet aggressive business goals. Such conditions inhibit communications beyond what's absolutely needed to get the project done, and by doing that they breed architectural diversity, or non-compliance if you prefer.

When a new employee, an offshore team, or outside consultants lead a project, they often lack background needed to avoid hidden side effects and match prevailing development styles. Inspections enable seasoned developers familiar with the territory to pass knowledge to the project team. Their advice helps the team avoid unforeseen risks that otherwise emerge only in integration test. It also helps the outsiders conform to the environment's accustomed styles and patterns, reducing learning curve and therefore costs during maintenance and enhancements.

But beyond particular projects, adding mandatory walkthroughs or inspections to the project cycle creates a forum for establishing and evolving those development styles and patterns, transferring knowledge from senior to junior developers, resolving difficult technical issues, and incorporating new methods and technologies, in short building an effective app dev culture. Over time that effective culture will tend to reduce maintenance costs as design and development standards conform to patterns, and reduce turnover as the group builds cohesion and mutual support.

Whether or not you apply inspections with sufficient rigor to gain the benefits that Jones and Bonsignour cite, making such gatherings a part of your development process will increase productivity and reduce costs, with the side effect of making your company a better place to work.