When to Refactor Code — and When to Leave It Alone

Refactor when a cost shows up more than once. These are the signals worth acting on:

• You were slowed down twice in the same file this month. That tax is real, and it compounds.
• You're about to add a feature there anyway. Clean the room before you move furniture in.
• The same bug keeps coming back. Messy code hides bugs the way clutter hides your keys.
• The same 20 lines exist in three places. The next fix will miss two of them.
• A teammate asked what a function does, twice. Confusion spreads faster than tidy-up.

Notice what's missing from that list: "it looks ugly." Ugly code that ships beats pretty code that doesn't.

When to leave it alone

Most of your code should be left alone. That's not laziness, it's priorities.

• The code works, nobody opens it, and it earns its keep. Boring and running is a great outcome.
• A launch is next week. Bad refactors before a deadline cause more outages than bad code ever does.
• You have no tests. Cleanup without a safety net is risky editing with extra steps.
• Someone wants a full rewrite. See the next section before you agree.

Every shortcut you don't clean up becomes technical debt (a small cost you pay later for a quick decision you made today). But debt is only a problem when it charges interest. Dead code charges nothing.

Refactor vs rewrite: pick the cheaper option

A rewrite is the tempting move and usually the wrong one. Old code carries years of tiny fixes nobody wrote down: the customer who needs that odd date format, the tax rule from 2019, the one report that breaks if you sort differently. A rewrite throws all of it away, and you relearn it through angry emails.

The safer path is small refactors, shipped one at a time, with the old system still running. Teams call this the strangler pattern: new code grows around old code until the old part is simply never called again. You keep shipping the whole time.

What this means for you

Here's the practical version, whether you're a solo builder or managing a team:

• Budget refactoring like a chore, not a project. Thirty minutes a week beats a two-week "cleanup sprint" that gets cancelled.
• Fix what you're already touching. Leave each file slightly better than you found it, and don't wander into files you had no reason to open.
• If you're a manager, don't approve a refactor with no deadline attached unless the team can name the exact bug it prevents.
• If you're building alone, ship first, tidy second. People pay for features, not neatness.

Clean code isn't the goal. Working software is.

Key Takeaways

• Refactor when messy code slows you down twice, or right before you add to it.
• Leave stable code alone: working and boring is a win.
• Never refactor code you can't test first.
• Rewrite only when keeping the old code costs more than replacing it.

Frequently Asked Questions