The Japanese manufacturing revolution--a combination of lean production, quality techniques, and sheer necessity–lifted the Japanese industrial phoenix out of the ashes of World War II until it eventually dominated world manufacturing. The concepts used to rebuild the empire can easily be applied to the software development industry. In this week's column, Clarke Ching describes why the majority of the software industry has done a poor job of incorporating these quality techniques and reveals the one secret ingredient that makes them easy to adopt.
"Inspection with the aim of finding the bad ones and throwing them out is too late, ineffective, costly. In the first place, you can't find the bad ones, not all of them. Second, it costs too much. Quality comes not from inspection but from improvement of the process."
[W. Edwards Deming, the American statistician who drove Japan's post-war quality revolution]
The late W. Edwards Deming, an American statistician, was widely credited with providing much of the know-how and philosophy that drove the Japanese recovery. Ironically, his know-how was developed in America where it was largely ignored. Deming was sent to Japan in 1947, but it wasn't until 1980 when NBC featured him in a television program "If Japan Can ... Why Can't We?" that the West finally took notice. Deming's message slowly spread from Japanese manufacturing into western manufacturing, then into the western service industries.
Deming's key message was to build quality into the processes rather than inspect defects out of a product already built. Although his concepts are acceptable to software development where quality is job number one, the concepts have either not actually been applied or not well. The majority of software development projects still follow the waterfall lifecycle that relies on inspecting defects out, that is, testing the product to remove defects.
Late inspection and testing are the simplest, most expensive, and least effective way to find bugs. Before manufacturers adopted modern quality techniques their main approach to removing defects was to inspect each product in the last stage of production once it had been built, but before it was shipped. If the product didn't meet specifications, then it was either reworked or scrapped--both expensive options. Late inspection is prone to human error and rarely finds all defects.
Late inspection is also the model primarily used when doing waterfall software development. Rework (which the waterfall is meant to minimize) is pushed to a phase of the project when fixes are the most expensive, when the cost of change is forty to 100 times greater than if the defect was fixed when it was created (Boehm, 2004). This stage has the least wiggle room time to recover from show-stopper problems or unexpectedly large amounts of rework. This unpredictability becomes one of the main reasons why projects miss their schedules.
Recognizing the high cost of late inspection, manufacturers moved back the inspection process by using self and successive inspection. Self inspection involves operators inspecting their output immediately after processing it. Successive inspection happens when operators inspect the inputs from prior processes. The equivalent processes in software development are walk-throughs, inspections, and unit testing. These approaches provide much earlier feedback when the correction costs are much lower, but still rely on human judgment.
Mistake Proofing--Building Quality into the Process
A more powerful approach is to design your processes to automatically prevent defects from happening. The Japanese name for such techniques is Poka Yoke, meaning mistake proofing. Poka Yoke has two aspects: prevention and detection. For instance, having different shaped plugs for each type of connection in a PC prevents novices and experts from making mistakes when installing a new PC, and the electric fuses and circuit breakers in your home detect when electrical circuits are overloaded which prevents electrical fires.
Likewise, one of the most common causes of defects--ambiguous requirements--can be prevented by writing comprehensive acceptance tests when each requirement is captured. Furthermore, automating these tests and running them as part of frequent integration-builds help detect defects when they happen.
The Missing Ingredient
Deming's core message was that we should stop inspecting defects out of products