The Value of Finding and Fixing Non-Critical Bugs

We've all been there. You’re triaging bugs and you come to a bug, and everyone on the teams starts nodding: "Ah yes, I remember this one." In any even semi-complex software system, there are plenty of bugs that people are aware of, yet never seem to get fixed. Why? Well, they aren't bugs that block any functionality of the system, and so they are never prioritized above other blocking bugs. And, there are plenty of bugs that block functionality. Thus, it follows that in any such system, there will be a collection of these "small" bugs that build up over time. But, what should we do with these bugs?

There are (as often seems to be the case) essentially two basic options:

1. Fix them.
2. Disregard them.

The worst thing to do would be to simply have the team triage them regularly and not fix them. In that case, you are simply wasting developers’ time. So, you either save your developers' time by marking these bugs as "known" and removing them from future triages, or you invest the time and resources to get them fixed. And while any developer reading this knows in their bones that only one of these options feels right, we all know how difficult it can be to actually convince product owners and management that these small, non-critical bugs are worth the effort. So, allow me to equip you with some reasons that fixing these bugs is worth it, for everyone.

Firstly, it is important to distinguish which of these bugs are "simple" to fix and which are "difficult" to fix. For all of the bugs that are "simple" to fix, a developer adept in the codebase should be able to resolve about a dozen of them in a focused day of work. This is a minimal investment of time and resources for the product owner. The rewards, however, are far from minimal.

While these bugs don't block functionality, it is highly likely that there is a group of users that find that particular bug particularly annoying for any one of them. And it is likely that each bug has a slightly different group of users that it annoys. If you imagine only 1% of your user base is annoyed by one of these bugs—and that there is essentially no overlap in the groups that each bug annoys—taking one day to fix 10 of these bugs would increase you customer satisfaction by 10%!

But a system's users aren't the only people that management and product owners should consider. It is also imminently important to keep your "developer satisfaction" high. Few things are guaranteed to annoy almost any developer but knowing about a simple-to-fix bug and being disallowed from fixing it is one of them. Developers want to take pride in their work and in the system that they are contributing to. Development teams need to foster this impulse. Help your developers feel a sense of ownership in their work, a pride in even the small contributions they can make. I promise you, if you allowed one developer every sprint to have one day to fix any issues in the system that he or she wanted, your entire team would be more engaged and more motivated by the time each of your developers had their opportunities.

So, don't let these "insignificant" bugs pile up. Take advantage of this hidden treasure trove of potential customer and developer satisfaction-improving nuggets and invest the time to start getting them fixed. Like the customers who will thank you, you can thank me later.