标签: root cause analysis

Regular readers know I'm a big fan of code inspections. Overwhelming evidence and common sense has shown that two heads are better than one at finding problems, and adding another team member or two yields even better code. But inspections suck. Few developers really enjoy them. I sure don't, but we're professionals hired to build systems as efficiently and as perfectly as possible. A doctor might not enjoy giving prostate exams much, but to avoid such tests just out of personal distaste is both unprofessional and unacceptable. The same goes for the unsavory bits of our work. Because of this common aversion it's not uncommon for a team that starts with all of the best intentions to slowly find reasons to avoid reviewing code; that nearly always eventually results in inspections becoming completely abandoned. Because of this I feel inspections are one of the few areas where Genghis Khan software management is appropriate. A strong leader insists on their continued use. That person both supplies the resources needed and audits the process to insure compliance. But you don't want management on the inspection team ( developers tend to avoid pointing out errors when the boss is around, out of respect for their colleagues ). So how can one insure the team is doing the right things? The solution is root cause analysis , used statistically. From time to time the boss should identify a bug that was found and perhaps fixed, and have the team or even a member of the team figure out how the mistake made it into the code. Was an inspection on the affected code ever done? How much time was devoted to it? Were other problems identified? ( This implies collecting metrics, which is nearly painless when automated with tools like SmartBear's Code Collaborator ). It's possible the function was unusually complex and the review did find many other problems. So, were complexity metrics taken? Or gasp did the developers shortchange the inspection or skip it altogether? Perhaps the bug slipped in later, post-inspection, due to poor change management procedures. Bugs are part of the process, but proper bug management should be an equally important component. It's not possible to do a root-cause analysis of every, or even most, problems. But some level of it keeps the developers on the proper track and can identify flaws in the system that cause delays and quality problems. C.A.R. Hoare said: "The real value of tests is not that they detect bugs in the code but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code." And that observation is also true for looking for root causes of at least some of the bugs.

Regular readers know I'm a big fan of code inspections. Overwhelming evidence – and common sense – has shown that two heads are better than one at finding problems, and adding another team member or two yields even better code.   But inspections suck. Few developers really enjoy them. I sure don't, but we're professionals hired to build systems as efficiently and as perfectly as possible. A doctor might not enjoy giving prostate exams much, but to avoid such tests just out of personal distaste is both unprofessional and unacceptable. The same goes for the unsavory bits of our work.   Because of this common aversion it's not uncommon for a team that starts with all of the best intentions to slowly find reasons to avoid reviewing code; that nearly always eventually results in inspections becoming completely abandoned.   Because of this I feel inspections are one of the few areas where Genghis Khan software management is appropriate. A strong leader insists on their continued use. That person both supplies the resources needed and audits the process to insure compliance.   But you don't want management on the inspection team ( developers tend to avoid pointing out errors when the boss is around, out of respect for their colleagues ). So how can one insure the team is doing the right things?   The solution is root cause analysis , used statistically. From time to time the boss should identify a bug that was found and perhaps fixed, and have the team or even a member of the team figure out how the mistake made it into the code.   Was an inspection on the affected code ever done? How much time was devoted to it? Were other problems identified? ( This implies collecting metrics, which is nearly painless when automated with tools like SmartBear's Code Collaborator ). It's possible the function was unusually complex and the review did find many other problems. So, were complexity metrics taken?   Or – gasp – did the developers shortchange the inspection or skip it altogether?   Perhaps the bug slipped in later, post-inspection, due to poor change management procedures.   Bugs are part of the process, but proper bug management should be an equally important component. It's not possible to do a root-cause analysis of every, or even most, problems. But some level of it keeps the developers on the proper track and can identify flaws in the system that cause delays and quality problems.   C.A.R. Hoare said: "The real value of tests is not that they detect bugs in the code but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code." And that observation is also true for looking for root causes of at least some of the bugs.