I disagree. I think the boy scout rule applies but should be interpreted as follows: when you see technical debt, you should try to fix it, but when this would

I disagree. I think the boy scout rule applies but should be interpreted as follows: when you see technical debt, you should try to fix it, but when this would take too much time, at least fix it a bit. This way technical debt will be fixed eventually, but it doesn't disrupt the timeline of the current sprint/ project too much. E.g.: suppose you are fixing a bug in some part of the application that was not written by you, for instance it could be written a while ago by a colleague who's no longer here. And you notice that the code is written so badly that it takes you a long time to understand. What you should do is: - write tests that verify the code behaves as expected - fix the bug (so the tests succeed) - refactor the code until you think the next colleague who's reading it will be able to understand it. If this is too much work to do all at once, at least fix the most urgent parts. This is the well known 'red, green, refactor' mantra.