[bgribble]

I'm conflicted about this. Definitely am a fan of "leave it better than you found it", refactor as you go, etc.

But when it comes to bug fixes, the "absolute minimum" is often the best approach -- it can be explained to demonstrate that we know precisely the root cause of the problem, it can be reviewed for correctness readily, and we can feel good that we are not adding a lot of new behavior that can have downstream effects. The "defensive programming" approach.

A refactoring that makes the problem go away forever is an awesome tech debt project, but when you have a hot problem and someone puts up a 1k LOC PR to refactor the problem away it often introduces so much uncertainty that the improvements aren't worth the risk. You have to start asking questions like how long has this person been around, do they understand what they are doing here, have they really tested this fix or does it just have good "coverage", do they really understand the root cause of the problem or is this just a "refactor and pray it goes away" fix...

A small-as-possible fix relies much less on the credibility of the code author and much more on the fix being self-evidently correct.

[pphysch]

"Absolute minimum" in practice usually means hard-coding a special case/workaround directly into a live prod instance. That is the quickest and 99% of the time won't cause any operational issues in the short-term. It happens all the time and contributes enormously to technical debt.

[JohnFen]

It's a judgement call. If you're maintaining software, it's true that every time you touch the code -- even to fix a bug -- you're taking a risk that you're introducing a new bug. Refactoring software is an even greater risk.

So, in general, the instinct is (and should be) to touch the code as little as possible. However, that's not always the right answer. The right answer is to do a risk/benefit calculation and choose the approach that is most likely to lead to an overall improvement.

Sometimes, that means change as little as possible to fix a bug. Sometimes, that means refactoring a major piece. It all depends.