Refactoring projects fail. Refactoring routines succeed.
Every six months, someone proposes a “tech debt sprint.” Leadership approves it. Two weeks of cleanup. Then back to features. Three months later, the codebase looks the same. Six months later, the same conversation.
The pattern fails because it treats refactoring as an event instead of a practice.
What works: the boy scout rule, enforced. Every feature touches code. Every touch leaves it slightly better. Not a full rewrite-a small improvement. Rename that confusing variable. Extract that duplicated logic. Add that missing test. Make it stick through code reviews that ask “what did you improve?” and weekly recognition for good cleanups.
The math is simple. Ten engineers, five PRs each per week, one small cleanup per PR. That’s 2,500 micro-improvements per year. No sprint needed. No business case required. No permission asked.
The catch: it requires discipline. It requires leaders who set the expectation explicitly: “every PR includes one small cleanup.” And it requires understanding that “just ship the feature” accumulates the debt that makes the next feature take twice as long.
Refactoring isn’t something you schedule. It’s something you build into how you work.
What’s the last piece of code your team left better than they found it?