From Manufacturing to Software: The Evolution of Root Cause Analysis

Software engineers are the builders and designers of the applications we conduct all our digital activities. While making these ingenious and complicated applications, there are high chances of problems and bugs. Every company has a different route to finding the root cause of the problem. Among these techniques of Root Cause Analysis, we will touch upon the two most common ones I have encountered. The origins, pros, and cons of these two methods weighed together make them a paramount step to locating and removing the cause of the problem in a software engineer’s work.

What is Root Cause Analysis?

Root Cause Analysis (RCA) is a problem-solving technique used to identify the root/cause of a problem. It is a broad term comprising multiple techniques and methods adopted worldwide from various professions and industries. RCA includes analyzing the problem from all angles, collecting all the relevant data, and identifying and linking multiple factors that have ultimately caused the problem.? RCA isn’t limited to a specific industry’s problems. It is a universal technique and can be applied everywhere. In software development, this broad technique helps pinpoint a specific bug or shortcoming in the code.

The basic goal of RCA is to prevent the problem from happening again. The two most popular techniques for conducting RCA are the “5 whys” technique and the “Fishbone diagram.” Both of these methods will be discussed thoroughly here.

"5 Whys" and Its Origin

The 5 Whys technique involves asking ‘why’ questions 5 times to identify the underlying cause of the problem.? This simple yet intuitive method was first popularized by the founder of Toyota, Sakichi Toyoda . Now, an essential problem-solving approach not only in Toyota but globally in other industries and professions. Taiicho Ohno , famously known as the father of Toyota’s production system, summarizes the 5 whys concisely below:

"The basis of Toyota’s scientific approach is to ask why five times whenever we find a problem … By repeating why five times, the nature of the problem, as well as its solution, becomes clear."

Source: 5 whys

The 5 whys aren’t limited to car production factories but can be applied in any industry, especially software engineering. Let's see an example related to software engineering.

Example of 5 Whys in Software Engineering

In this example, we are facing a problem with software that is frequently crashing. We’ll see how asking a few simple questions can dig deep into the cause of the problem.?

Question: Why is a particular software frequently crashing?

1. Why was the software crashing? The source code has an error causing the bug.
2. Why does the Software have a bug? The developers didn’t test the application properly or overlooked a specific scenario causing the issue.
3. Why wasn’t the software tested properly to eliminate the bug? The developers didn’t have enough time to test fully.
4. Was there deadline pressure? There was indeed a time crunch as the deadline wasn’t predicted properly.
5. Why was the project timeline not estimated correctly? The developers were inexperienced; they overestimated themselves, causing them to come up with a short timeline.

Outcome: The inexperienced development team underestimated the scale of the application after creating a short window of time, which limited their testing ability.

The answers in the above questionnaire can change. But comparing the complexity and vagueness* of the first and last questions, we can see that asking a simple question (Like question 1) will often lead to more direct questions that answer our query.

Concluding 5 whys, we will explore its advantages and disadvantages.

Pros

• The technique is easy to use.
• Requires little to no formal training.
• It is an efficient problem-solving tool that requires little time.
• The method isn’t limited to software problems only. It can be used on other issues.

Cons

• This method isn’t recommended for solving large and complex issues.
• The questions have to be unbiased and objective. Otherwise, there is a risk of introducing biases in the analysis.

Fishbone Diagram and Its Origin

Fishbone is also known as the Ishikawa diagram or cause-and-effect diagram. Like the 5 whys, this method also originates in Japan. Renowned engineer Kauro Ishikawa developed this technique in the 1960s. It was widely used for quality management in numerous industries. The fishbone diagram helps professionals identify a problem's root causes by looking at it from multiple perspectives. A fishbone diagram is constructed where the underlying problem is stated first. The other branches of the fishbone represent different entities or bodies, such as people, procedures, equipment, environment, etc., which could’ve led to the problem. The diagram given below will help you understand and visualize this better.

Source: Fishbone diagram

Example of Fishbone Diagram

We will again limit our problems related only to software engineering. We shall look at another similar example to the 5 Ways example so that you can compare both methods easily. The only difference here is that professionals/the team will brainstorm potential causes of the problem and categorize them into appropriate branches.

Problem: The software is frequently crashing.

Branches

1. People:

Developers: Incomplete code, bugs in code, miscommunication.

Users: Misunderstanding the application, lack of training

Testers: missed bugs, incomplete testing

2. Procedures:

Documentation issues: Lack of documentation.

Quality control and standards: lack of quality control.

3. Equipment:

Hardware: Outdated computer configuration and obsolete technology.

Servers: Overloaded or inadequate

4. Environment:

Network: Poor internet (bandwidth limitations or latency issues).

High Traffic: Overloaded communication channels.

5. Product:

System configuration: incorrect settings.

Software application: compatibility issues.

Once the fishbone diagram has been created, the investigation team can analyze the potential causes shown/identified by each branch and subbranch. More than one branch can reveal problems. Moreover, this method helps to alleviate all the possible roots of the problem, which leaves the conclusion and solution more decisive. This is the beauty of the fishbone diagram method, as it helps to visualize brainstorming properly and leads to proper conclusions.?

Now, let’s dive into the pros and cons list to analyze the efficiency of this technique.

Pros

• This technique can be used for large and complex problems.
• Visual representation helps to record issues and contributing factors for future reference.
• Multiple contributing factors can be found.

Cons

• Special training might be required to use this method effectively.
• It is more time-consuming.
• The final diagram can become too difficult to interpret in larger problems.

Conclusion

There are many more techniques for conducting root cause analysis, but 5 whys and Fishbone are the easiest and most effective. Both methods are linked in many ways. It’s up to you to choose the method that will fit your requirements. “5 whys” is used for smaller problems, whereas the fishbone diagram is used for problems of larger magnitude.

Problems and setbacks are part of our lives. It’s up to us how we choose to deal with them. This applies to both our personal and professional lives. RCA might look tedious, but it surely does help in the long run, where our products must be reliable and trustworthy. If you are a software engineer, I highly recommend choosing the 5 whys and fishbone diagram methods to dissect your issue.

Have you used any other RCA technique? Please share your experience in the comments.