Julien Reszka
Refactoring has a good reputation. It sits comfortably alongside 'clean code' and 'best practices', phrases that nobody argues against in a meeting. The problem is that reputation hides a real cost: time spent restructuring existing code is time not spent on new features or fixing bugs that users actually encounter. CAST Research found that developers spend around 42% of their time dealing with technical debt. That number does not go down automatically when you refactor. It goes down when you focus the refactoring on the right things. Refactoring can create an illusion of progress, introduce regressions if tests are incomplete, delay work that directly affects customers, and produce over-engineered abstractions that increase complexity without increasing capability. The test for any proposed refactoring is two questions:
- Will it measurably increase development speed?
- Will it reduce the number of critical bugs that currently have no workaround?
If the answer is yes to either, the work is likely justified. If the answer is no on both counts, meaning the codebase will feel cleaner but ship at the same rate with the same failure modes, then what is being proposed is not delivery. It is comfort.
Discussion
Yes. We just spent a quarter on a refactor that 'cleaned up the auth layer' and our deploy frequency is identical. Critical bug count is identical. The two-question test would have killed it on day one.
Guilty. I refactor when I don't know what to build next. It feels like work because the diff is huge, but the changelog for users is empty.
That's the pattern to watch. Refactoring as a substitute for a roadmap decision.
Counterpoint: sometimes the 'refactor' is what finally exposes the real bug. Once spent two weeks 'cleaning up' a payments module and the cleanup is what surfaced a rounding error that had been quietly losing us money.