Several valid reasons for refusing to fix a bug

A bug occurs when something doesn't work as expected. A bug fix is ​​basically a patch to existing code that should fix the problem to ensure that "the feature" works as expected. However, the patch often fixes one thing but breaks many things. I believe it is necessary to reject bug fixes from time to time and ask their authors to rework the patch to protect the project from bigger problems. In my experience, there are some valid reasons for such rejections.

[[142609]]

"El Crimen Perfecto", Director: Alex de la Iglesia

It reduces code coverage

It's a very common scenario: after making a change somewhere, unit tests start breaking somewhere else. The bug is fixed, but some possibly unrelated unit tests start reporting failures. Due to pressure or just because we're lazy, we don't fix them; we just delete the tests or mark them as temporarily "skipped". The problem is fixed, the build is clean, so merge the patch and call it a day, right? Wrong!

Even though I like to cut corners wherever possible, I don't recommend that you do that in this case.

Unit tests exist precisely to prevent us from breaking code when we are under pressure.

Obviously there are some situations where unit tests are wrong and we have to delete them. For such situations, remember to create new unit tests.

There are also scenarios where a bug must be fixed as soon as possible to get the system up and running, and fixing all the unit tests will take an hour. This situation is a strong indicator that you are already in a terrible potential scenario, which is test coverage in the product. No doubt, we have to make the fix and make the tests pass after some time. However, in this case, make sure that the next task of the team after fixing the bug is to correct the broken unit tests. I recommend reading "The Art of Fixing Code" by Michael Feathers, which provides a correct answer to this topic.

The Art of Modifying Code by Michael Feathers

It does not reproduce the problem

Sometimes the entire system crashes because of a small typo in a line of code. The obvious bug fix is ​​to remove the typo, which is not what the project expects us to do if we care about the quality of the project. The problem is not the typo, but the lack of unit tests, which would have caught the error during the deployment phase.

The real problem is that test code coverage is missing for this part of the code. Simply removing typos will not help the overall project. Moreover, we are hurting it - we are covering up the real problem.

No matter how small the problem, no matter how confusing its manifestations, a bug fix must include additional tests that can reproduce the bug in the first place. Without such tests, the so-called bug fix is ​​just a waste of money for the project.

Furthermore, without unit tests that reproduce the problem, there is no guarantee that bug fixes will not introduce more bugs. I would even go so far as to say that the more bug fixes we make, the higher the entropy [Note 1] we introduce. The only way to reduce this uncertainty is to cover the code with unit tests. Without tests, bug fixes will introduce more disorder into the code base.

It's too big

Bug fixes are not features; they must be small and focused. Introducing some refactoring while fixing bugs is a common mistake programmers make when they are intoxicated. As a result, the patch is too big to understand. I am not against refactoring; refactoring is very important to a project and is a positive move, but it should be done after the bugs are fixed and merged.

Please do not refactor your code when fixing bugs!

Create a new unit test, reproduce the bug, and commit it. Fix the bug in the existing codebase, no matter how ugly it is. Create new bugs, asking the team to improve the situation of the ugly codebase. Assign these bugs to yourself if you are interested. Maybe someone else is just interested in fixing them and refactoring the code. But all of this will happen in other pull requests, with new code reviews and new merges.

Fixing bad code has nothing to do with laziness or unwillingness. It's a matter of discipline, which is more important than good intentions.

It doesn’t just solve one problem

Always fix one problem at a time - simple as that, no exceptions. When a bug fix patch contains code changes that fix multiple problems, it becomes difficult to understand which problem is tested, which is reproducible, and how they are related to each other. It is a very bad practice to combine multiple bug fixes into a single pull request.

No matter how simple the fix is, make sure it is separate from other fixes. Review the code, test it, and merge it one by one. This also increases the ease of tracking code changes, making it easy to understand who made the fix, who reviewed the code, and when it was merged (and deployed).