Andrey Agibalov There’s a myth buried inside the phrase “we’ll refactor it later.” It assumes refactoring is something that can be postponed — a separate phase of development, waiting politely at the end.
But refactoring isn’t a phase. It’s not something you do after the real work is done, or a smaller word for “big rewrite.” Refactoring is how you work. It’s the continuous act of shaping code so it better reflects what it already does — and prepares it for what you’re about to change. You refactor to make the next step not just possible, but organic.
Sometimes that means clarifying intent; other times, it means introducing the right seams — the extension points, the boundaries — that let new behavior grow naturally instead of being bolted on later.
That’s why refactoring can’t be scheduled. The longer you wait, the harder it becomes to understand what you’re changing. And once understanding fades, what you call “refactoring” quietly turns into re-implementation. That’s how big rewrites are born — out of code that became too tangled to evolve incrementally.
Healthy systems evolve in place. They’re continuously rewritten, one small step at a time. Refactoring isn’t a project to plan or finish — it’s the rhythm of development itself.