3

In our group we usually don't ponder too much about what kind of design or implementation decisions caused a bug, we just fix it. Of course if some module constantly produces bugs people start to notice it, and sometimes this leads to major refactoring. But we don't have a process where bugs are routinely analyzed for their root causes.

My question is whether a formal process of bug root cause analysis is common in software development, and if not why not.

Eugene
  • 1,943
  • What do you mean by "common?" Are you asking about popularity? – Robert Harvey Jun 16 '14 at 16:15
  • Yes, if only 10 percent of development teams do this then it might not be a good process to follow – Eugene Jun 16 '14 at 16:16
  • 7
    That's a terrible metric. Processes used by teams building one-off mobile apps to book hotel rooms can't be compared to processes used by teams building the next generation of radiation therapy machines or aerospace components. – Thomas Owens Jun 16 '14 at 16:21
  • Sometimes, I have found asking "Why will something like this not happen again?" immensely useful. It forces discussions that are otherwise missed. Over time, it somehow also catches on and as more folks start asking this question, many root causes analyses end up happening impromptu. Of course, there're other times when it's far more formal with multiple meetings and task forces created esp. when the stakes were high (system overcharged customers, serious security issue, etc.), and it sometimes, it just depends on the project like @ThomasOwens said. – Omer Iqbal Jun 16 '14 at 17:11
  • @Eugene: If 10% do it, its being done far more often than any other task or methodology..... – mattnz Jun 17 '14 at 03:05
  • @ThomasOwens even worse, it's pretty well possible that 10% of people do something for the wrong reasons... Or even 75%. – jwenting Jun 17 '14 at 08:14

2 Answers2

4

If you are employing lean software development practices, then examining the root cause of defects should be part of your development process. Defects are one of the wastes - defects that go undetected as development happens cost time, especially as either they go from activity to activity (requirements defects slipping through design or even into integration and acceptance testing activities) or go undetected as the complexity of the system increases (as new features are added). Extending some effort to understand why defects aren't being detected early within the process and making changes to improve defect detection in upstream activities is part of maintaining a lean organization. However, it's also important to note that the cost of performing a root cause analysis is weighed against the benefits - it may not be every defect that is examined, but perhaps as a result of one iteration, there were a large number of defects that can be categorized and analyzed in groups to improve future iterations.

As far as structured methods go, there isn't a single standard approach. It depends on the problem and the team. Some methodologies include Eight Disciplines, DMAIC, Plan-Do-Check-Act, and others. Using these methodologies, you may employ tools such as orthogonal defect classification, fault tree analysis, 5 Whys, Ishikawa (fishbone) diagrams, and nominal group technique, among others (see the Seven Basic Tools of Quality for examples, although these primarily come from manufacturing and industrial processes and may not all translate one-for-one to software development activities), to narrow down the scope of the problem, identify commonalities, and get to the root causes and possible solutions.

If you're looking for a common process that exists across organizations, there really isn't one. However, a lot of the methodologies and tools are common. They are just broken down or used slightly differently across organizations and teams. You ultimately need to determine what works best for you and your team, in terms of defining the problem, determining the best methods to investigate and identify root causes, developing solutions and verifying that they are correct, and ensuring that they are having a positive impact on the process.

Thomas Owens
  • 82,739
0

The nature of causes is very different and bug cause analysis is often mistaken by analysis of the origin of a bug. For example imagine the wrong adaption of design patterns in contrast to a bad application design or simple programming mistakes.

So I think there will never be a formal process. Maybe the 5-Why-Method will take you to the root cause, but this is more a technique than a formal process.

shylynx
  • 2,134
  • There are several formal processes for problem solving - PDCA, DMAIC (often found in Six Sigma environments), 8 Disciplines, and some proprietary methods build around commercial tools. There are also a number of formal tools. There will likely never be a single standardized process across organizations, but there exist well-defined and used standard processes within organizations (often based on a standard model) for performing root cause analysis, often with the same quality tools. – Thomas Owens Jun 16 '14 at 16:13