A headache and a bug have something in common. When I have a headache, I take an effervescent paracetamol tablet. The noise from the bubbles and the flavouring makes me feel better. Although the paracetamol will make the symptom, pain, fade away, it won’t help me find and fix what caused the headache. Could it be too much screen time, not drinking enough water or poor nutrition? The medicine solves the symptom, not the cause. The pain goes away, and then I forget to look into what might be the cause. The same thing happens in the software engineering world. As developers, what tools and techniques can we use to force ourselves to think beyond symptoms?

See the system

It is not easy to find the root cause of a problem. Think about the flu or, more recently, coronavirus. We don’t know how it started. Could it be a lab leak, animal trafficking or too much international travel?

Finding the root cause of a bug and fixing it requires thinking within a wider frame. The root cause could be organisational, architectural or hiding behind habits. Patching the front end of a website is sometimes faster and easier than fixing the organisational problems of the company. Still, attempting to fix the root cause is a worthwhile exercise.

The 5 Whys technique developed at Toyota makes you ask “why” five times to find the problem’s source. This method is great to get past the symptoms and find the root cause. It forces you to think about non-obvious answers.

A visual tool that complements this technique is the Ishikawa diagram, invented by the Japanese management expert Kaoru Ishikawa. It is also called the fishbone diagram for its resemblance to a fish. This type of diagram depicts a root cause analysis of a problem by listing all the possible categories and causes that led to an issue. For example, a loss of user data could not only be caused by developers but also by management or a lack of tools.

Contemplation

Fixing a bug feels good. You feel helpful and often will be congratulated by colleagues. Before frantically jumping on Stack Overflow and copy-pasting an error message in the Google search box, take time to think by yourself. I remember a day when we had a severe database problem. Everyone in the team was looking into the issue. No one knew who was responsible for what or which area they should be looking at. No one took the lead because everyone was heads down and not talking to each other. Being more contemplative instead of reactive will help reduce stress and keep a clear head.

Infinite games

The Finite and Infinite Games book argues that humans play two types of games.

”A finite game is played for the purpose of winning, an infinite game for the purpose of continuing to play.”

I once worked at a place where one developer would create new features and fix bugs without consulting the team for opinions. They were a success with the “customer” because they gave them what they wanted. It was a catastrophe for the team: the changes were not thoughtful or part of a coherent vision.

The finite-game developer will make quick fixes with a narrow frame. They will gain popularity, fame, and promotions.

The infinite-game developer will seek long term benefits. A new feature or change is part of a more comprehensive vision: it is well designed, and the team will have a plan to support it in the long term. They will do the grunt work that will enable the team to perform better in the future.

When a bug arises, the question you want to ask is: what can I learn from this problem and do in response that will benefit the future of the project and team?

Conclusion

Sometimes we jump to conclusions too quickly and hastily try to get around problems. We play a short game. Making a habit of finding and fixing the root cause of problems will benefit you in the long term. Today we reviewed four techniques and mental models to help us get over simple symptomatic fixes:

• Asking “Five Whys”
• Using an Ishikawa or fishbone diagram
• Thinking in terms of finite and infinite games
• Balancing reactiveness and contemplativeness