Debugging: the biggest waste

How companies are burning an incredible amount of money with debugging

Developers spend 50% time debugging

According to a recent research, developers spend ~50% of their time on debugging.

⚠️ 50% ⚠️

Let that sink in, and think about how much money is wasted on debugging in companies. Debugging means we don't know how the code works. Literally, the developers don’t know how their code works 50% of the time! How could they get to this point? How can they allow themselves to spend such an amount of time on an unproductive activity?

It all boils down to the increased feedback loops they work with. Being an expert in debugging is a smell: it means that we waste too much time debugging our code. Debugging is not bad per see. It is just a huge time-consumer. Every time we need to use the debugger, it implies that we do not know how the code is working. It indicates a lack of frequent testing. Debugging is an unproductive activity where the only thing we do is figure out how our code works. Nothing more. It is a hell of a waste.

Every time we need to spin up the debugger we should ask the question of how we reached that point. Often, it’s because we increased our feedback loops. Debugging implies that we lost touch with the state of our code. How can we significantly decrease our feedback loops and be sure that our code always works as expected? I’ll soon reveal the solution.

Zero bug policy

Bugs are the worst enemies of a software engineer. They can easily sneak into the code, they are difficult to spot, and they can cause huge damage. The main problem with them is that they can significantly damage our reputation with our customers. It is a big deal given the fact that our most important task is to make our customers happy. Apart from the reputational damage, they waste resources and increase costs because of the time we need to fix them. It is also not a rare thing that a company needs to close its doors due to a critical bug, especially in the fintech world. All of these mean only one thing: we have to prevent and get rid of bugs at any cost.

Having many bugs is an indication of poor software quality. Companies treat bugs as inevitable mistakes, then choose to burn an incredible amount of money to fix them. Companies should stop managing bugs and start focusing on quality instead. Introducing zero bug policy would be the first step ahead. Zero bug policy is a way of thinking and doing that reinforces the idea that bugs are not acceptable in software.

It is a proactive approach: bugs take priority over all new features and other software improvements. Its main idea is that once a bug is discovered, we have to fix it right away. It does not mean that we need to fix all the defects we find. If fixing a bug would deliver no value, just let it go. We either fix a bug or close it. Dead simple. Deferring a bug is not an option. Tracking, maintaining, and managing deferred bugs requires extra effort. Picking up the bugs to work on, prioritizing them, and understanding them after several months they occurred, all take a lot of time and money. Instead of introducing an additional process of solving bugs, we should solve the culture of quality instead. We need to set up an environment where bugs are not acceptable. We should raise the bar of the quality standard. Zero bug policy will make the developers feel more responsible for the work they do.

TDD fixes this

Among many other things, Test-Driven Development fixes this. TDD is all about the frequency of feedback. It lets us fail only a little with a small cognitive overhead, where the changes are cheap. It helps us to quickly recover from mistakes, and most importantly, to avoid any big mistakes in the code. TDD leaves us the capacity to easily react to breaking code. When we write code with TDD, we can forget about using the debugger. By doing TDD, we get continuous and quick feedback about the code we produce. We continuously verify our software by running all our tests after every small step we make. We always know how the code works. Every minute, all the time. Test-Driven Development is a fully automated short-cycle-based debugging. It will make manual debugging redundant.

On top of that, the TDD flow will make sure that you write code according to the contracts expressed in your tests. It will result in a working and bugless code conforming to your expectations. The code will behave exactly as you expect. Another powerful thing about TDD is that it creates a strong safety net as a byproduct, in the form of automated tests. A trustworthy test suite with maximized code coverage and behavior coverage. A test suite where we can confidently change the code without introducing bugs in existing functionalities. TDD will substantially prevent regression bugs in your software.

Average developers fix the bugs in their systems. Good developers test the bugs out of their system. Great developers design them out by using Test-Driven Development.

Debugging is still essential

We still should not forget that debugging is an essential skill to have. There will be times when there is an unexpected bug in our application. After all, we are all human beings making mistakes. A bad day can come, and the nasty bug can sneak into production. Debugging will be crucial to quickly mitigate such issues. Debugging will also come in handy when working with legacy codebases. With legacy, I refer to code with no tests and with no test in mind when being developed. As software engineers, we do not always work on greenfield projects. Using the debugger will be sooner or later inevitable. On the other hand, using the debugger should be our last resort and we should strive for minimizing its usage by applying Test-Driven Development.

Closing my thoughts with the words of a good friend of mine:

We should be ashamed of debugging, not because we can always avoid it, but because we want to provide the best possible user experience for our users. - Tiger Abordi