I understand where you’re coming from. I would argue that if the amount of refactoring required to make the bug clear takes that much longer, then all the more

I understand where you’re coming from. I would argue that if the amount of refactoring required to make the bug clear takes that much longer, then all the more reason it should be prioritized. This is really the purest definition of tech debt, because there may be other bugs present in the code you are unaware of. This is assuming no tests cover the bug, because if they did, it wouldn’t have made it into production. Honestly you should be doing it all, because you have to understand the full scope of the issue to properly fix the bug, test it to prevent regression, and in order to test it it must be testable. So I would say if there are no tests, and it is not testable code, the least amount of refactoring you should do is make it testable. You actually don’t even have to write the test if you really want to cut corners. Just through single responsibility principle, dependency injection, and writing code that could be tested is enough to bring it 90% the way there. You can even break the dependencies and theoretically as long as you don’t violate the interface the functions you refactored should hold up. The simpler and more broken down the code is, it gets to the point where you say, this function has one if statement and two return statements, writing a test is actually redundant compared to the code. If it’s not mission critical code, you can really cut corners, if you’re in a hurry…