A classic paper from IBM shows how they systematically reduced defects by analyzing root cause. The cost of implementing this practice is less than the cost of fixing defects that you will have if you do not implement it so it should always be implemented.
1. First understand your architecture and where the bugs are coming from by type, severity, component, and point of injection during the development life cycle.
2. You will find 80% of the bugs come from 20% of the code. Mapping these defects on a component architecture will show swarms of bugs around specific components.
3. Apply bug spray through a carefully prioritized automated testing strategy. Find the biggest problem that occurs when doing final regression testing prior to deployment. Implement an automated test that makes this problem impossible to happen again using the detailed knowledge developed about bug infestation in your product. Write a single test that can prevent 100 common problems. Then go to the next highest priority problem and repeat. Doing a few automated tests a week will eventually make your build bullet proof with remarkably few tests.
In three months, one of our venture companies cut a 4-6 week deployment cycle to 2 weeks with only 120 tests. It took one person three weeks to write the test and eliminated several weeks of work by an entire team. It reduced defeats, radically reduced support calls, and the customers liked the new release enough to buy more product, raising revenue.
Everyone should implement this. The return on investment is astronomical. I thought this was basic stuff but our investors say almost none of their companies have implemented it until we invested in them. The developers are often junior, right out of university, and the managers are domain experts, not engineering experts. We have to teach them the basics.
by R. G. Mays, C. L. Jones, G. J. Holloway, D. P. Studinski
IBM SYSTEMS JOURNAL. VOL 29, NO 1, 1990
Defect Prevention is the process of improving quality and productivity by preventing the injection of defects into a product. It consists of four elements integrated into the development process(: 1) causal analysis meetings to identify the root cause of defects and suggest preventive actions; (2) an action team to implement the preventive actions; (3) kickoff meetings to increase awareness of quality issues specific to each development stage; and (4) data collection and tracking of associated data. The Defect Prevention Process has been successfully implemented in a variety of organizations within IBM, some for more than six years. This paper discusses the steps needed to implement this process and the results that may be obtained. Data on quality, process costs, benefits, and practical experiences are also presented. Insights into the nature of programming errors and the application of this process to a variety of working environments are discussed.