Bugs, the most misunderstood creatures in Software Engineering

We see bugs as mistakes. There is really nothing good about them and that is why we do not want to be associated with them. There are tons of articles out there about how to prevent them from happening, but no one talks about the psychological impact of how we handle these bugs. In this article, we look at bugs from a different angle. But first, let us understand what a bug is. 

What is a bug?

Bugs are errors, mistakes or flaws in a system. In other words, when there is a mismatch between our expectation and the actual result of an operation in a system, we say there is a bug in that system. We need to understand that everyone has their own expectation of a function and not everybody necessarily agrees on what to expect. This is why the existence of a bug is subjective. You can read about the history of bugs here.

What do Agile methodologies have to say about bugs?

To align these expectations, we can only rely on our requirements and specifications. Some of these documents are one liners, and some cover every detail! And when we think we have covered everything, a new uncovered scenario shows up at our door. We align the expectations and update the documents to cover everything. But soon we find ourselves in a never ending loop of updating our requirements. This issue has led us to come up with agile manifesto which prioritizes “working software over comprehensive documentation”.

But we have decided to be agile because we can truly benefit from it. So how do we handle these creatures that even their existence is questionable in the first place?

How to handle bugs to minimize distractions?

Since we know bugs are subjective, the first step is to align the expectations and agree on how the system should behave under certain conditions. Next, we apply the necessary changes according to our product prioritization. This means, we treat these changes just like any other features and there is need to separate bugs from other incoming changes. There is no need for any statistics or reports at this point.

While customers get the benefit of applying the changes, seeing patterns in these changes tend to tickle managers. This is when things go wrong for an inexperienced manager who, with all good intentions, tries to improve his/her team and product. To bring awareness into the team about these patterns, the manager uses numbers as a supporting fact. But to the team, these numbers mean the number of times someone messed up. And since no one likes to be associated with mistakes, the blame game starts. This is when we spend countless hours in the meetings. Instead, by treating those bugs just like any other changes, we take away the chance of creating such reports from everyone and build focus on what really matters.

Never stop asking “why”

Now it is time for self improvement initiatives which can be started by asking “why” some of  these changes were created in the first place and how we can minimize our effort by working smarter. Let’s keep in mind that no one makes deliberate mistakes so approaching this part carefully is very important. Lack of communication and poor communication skills are two common scenarios that worth considering in our quest to find the root cause.

Once the root cause is identified and the expectations are set in the team, it becomes clear to everyone what needs to be done next. It can be updating our CI pipelines to capture more scenarios or help someone to pick up a new skill.

We looked at how the word “bug” carries negative meaning and how we can simply minimize the number of changes by aligning the expectations and finding the reason behind the changes. By considering the psychological impact of our actions, we can build a culture in a team that everyone focuses on what matters the most: deliver value to the customers and work smarter to grow our business while we minimize distractions.

%d bloggers like this: