11.3 Root-cause analysis

There is a variety of bug-tracking systems available today, both commercial and open-source. Bug-tracking systems are necessary for any organization that maintains medium- to large-scale systems. While they’re useful, however, bug-tracking systems merely record the process through which a defect report goes.

The really valuable information generated by this process is only gleaned at the end of that process and often isn’t recorded. The most valuable information to be gained from diagnosing a bug is why the problem occurred. The process of determining the earliest point in the design and implementation of a program that a defect was introduced is called root-cause analysis.

Doing root-cause analysis is important for several reasons. First, it keeps you from fixing symptoms. Second, it enables you to improve the quality-evaluation methods for the phase of the development cycle in which the defect was introduced. Finally, it makes it easier to find similar bugs sooner in the future.

Programmers are sometimes unwilling to record this information because they fear that authority figures may abuse it. In some situations, this fear may be justified.

Managers looking for programmers to downsize may decide to choose staff based on false conclusions derived from root-cause-analysis data. For example, they might choose to terminate those programmers who have the most root-cause records logged against software they worked on. Or, they might withhold raises from those programmers who submit the most root-cause records.

These are both foolish choices, since these phenomena may be explained by reasons other than programmer incompetence. In the first case, uneven test coverage can cause one part of a system to look more defective than others, even though the opposite might actually be the truth. In the second case, the programmer who submits the most records may in fact be the most diligent tester in his group.

As a result of the potential for these abuses, organizations that attempt to collect root-cause-analysis data sometimes promise not to keep individual records, but statistical summaries of the information. After a programmer enters root-cause information, it’s immediately aggregated with totals, counts, averages, and so forth. Management can see trends, but can’t evaluate the work of individuals.

As you develop a database of root-cause-analysis records, you will be able to focus a debugging search on the errors you make most frequently. Another value of this database is being able to recall problems you have fixed that were similar to the problem you’re currently working on. This will enable you to diagnose more quickly and thereby fix more defects over a fixed period of time. See Chapter 8 for further discussion on similar problems.

Statistical summaries of your root-cause analyses can also be useful. They can tell you where you need to brush up your skills or employ additional “defensive programming” tactics to avoid the problem in the future.

If the people who supervise you aren’t asking for this information, you can keep it anyway and become more productive than your peers. As a student, you should get better grades by completing your assignments with less effort and with greater quality. As an employee, if your employer rewards you based on performance, you should earn more by getting your software to market earlier than the competition and with fewer customer complaints.