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&#x27;t disrupt the timeline of the current sprint&#x2F; project too much.<p>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&#x27;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&#x27;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.<p>This is the well known &#x27;red, green, refactor&#x27; mantra.