When to Refactor Code for Improved Quality

Don’t refactor working code just because you don’t like they way it was written. - Refactor when you need to make way for a new feature (small or large, just keep the refactor proportionate). - Refactor when you need to make performance optimizations. - Refactor when the code is a frequent source of bugs due to its obscurity. This is not an exhaustive list by any means. The common denominators are that the refactoring is both opportunistic and it serves a clear purpose. Refactor when you have a legitimate reason to do so. Don’t overdo it. #softwareengineering

When to refactor? Refactor when you can define real value that aligns with team priorities. "I'm refactoring processing logic because it's just terrible" ❌ No clear value. Lackluster communication. Perhaps a bit of ego — not a good reason to spend valuable dev time. "I'm breaking apart a payment flow to accelerate an initiative and de-risk a feature launch" ✅ Now we’re talking. You've thought through the outcome, and you know exactly what change will get us there. Huge difference. How do you decide when refactoring is worth it? Comic Relief - When Refactoring Has Gone Too Far

📣 If you are creating a user story for refactoring, I'm not sure you know what either of them are Cleaning up code while working on a change? Sure, you certainly should do that. Rewrite a bunch of code with zero defined positive outcome other than "I feel better about it?" We should question that. Using logic or measures that aren't used routinely to justify other changes doesn't count. So you can't use something silly like LOC reduction to justify a refactor if your process and team doesn't routinely measure and use LOC as a quality marker. One could make a stretch and say that a reduction in cyclomatic complexity for a function (that has a nice test suite of the interface, not the implementation), might pass the bar for a "non-functional but valuable stand-alone refactoring". If we routinely stack-rank code-complexity reduction tasks based on cyclomatic complexity, then this is a completely valid standalone task, but it's not refactoring for the sake of it, but based on a deterministic function we've decided to assign value to. Performance improvement, cost improvement - none of these are "refactoring" - it's changing code and config to meet a known objective that you can measure. No measurable result we care about - no code change. *of course this doesn't apply to personal projects or many open source contributions #meatbasedengineer