A short note on what "refactoring" should mean in 2025

We had three kickoff conversations this month where the word "refactoring" had quietly absorbed three different meanings: a rewrite with a softer label, a cost-cutting program led by finance, and a research spike with no production target. Each is a legitimate piece of engineering work, but conflating them with refactoring leaves teams confused about scope, ownership, and the success criteria.

In our practice, refactoring is the patient act of changing internal structure without changing externally observable behaviour. The qualifier "without changing externally observable behaviour" is doing real work. It is what separates a refactor from a rewrite, and it is what makes refactoring safer to schedule into a delivery roadmap.

The three distortions we keep encountering are the rewrite-in-disguise (where the team plans to replace the system but calls it modernization to soften the budget conversation), the finance-led cost program (which often refactors no code at all, only contracts and reservations), and the research spike (a valuable activity, but it should not block delivery on the assumption it is producing a refactor).

We say this not as gatekeeping but to keep the meeting honest. When we name what we are doing, we can scope it, schedule it, and accept the limitations of the chosen approach. Calling everything a refactor flattens the conversation and tends to disappoint at least one stakeholder by the second sprint.