Introduction
Asking the 5 WHYs is an approach to identifying the root of an issue.
If you don’t fix the root of issues, they will keep popping up.
Let’s take a look at a classic example.
What’s funny, I’ve been in this position myself as a developer. 😆
Example
This is a common example where developers do “quick fixes“ when fixing “small bugs“ that lead to more problems.
One problem on top of more bugs is you end up with a pile of untested behavior over time.
Problem: A small software update caused a major part of the program to stop working correctly in production.
Why did this major part stop working correctly?
Because the update accidentally messed something up.
Why did the update mess something up?
Because it was rushed through and not tested properly.
Why was it rushed and not tested properly?
Because the developer thought it was such a small change that it wouldn't cause any big issues.
Why did the developer think a small change wouldn't cause big issues?
Because they didn't fully consider how even small changes can have big effects in a complex software system.
Why didn't they consider the impact of small changes?
Due to a mix of being too confident in their own skills and not fully understanding how parts of the software are connected and affect each other.
There are many ways to prevent this from happening again as a team:
Test-Driven Development (TDD).
Make tests mandatory.
No bugs can be fixed except accompanied by a test.
No matter how “small“ the bug is.
I love the 5 whys approach. It helped me to eliminate jumping to conclusions and have a step back to think.
By nature I am inclined to take actions. This is not good when solving problems or debugging. You better take a step back and fix the root cause.
And, I must agree, asking 5 whys does miracles!