TL;DR
The author argues against treating refactoring as backlog work or a standalone story. Instead, teams should incrementally clean code as they touch it while building features, which yields earlier and more reliable benefits than a large, dedicated refactor.
What happened
The piece outlines a common lifecycle in software projects: code starts clean but accumulates small problems as teams rush to deliver features. Those issues compound over time, making routine changes slower and riskier. Asking product owners for a block of time to perform a large-scale refactor is often unsuccessful; if approved, it typically takes more effort and yields benefits later than anticipated. The recommended alternative is a disciplined, incremental approach: when developers work on a new feature, they should improve the code in the area they touch rather than detouring around it or waiting for a separate cleanup period. Over successive features this creates cleared paths through the problematic codebase, delivering improvements that begin to pay off quickly — sometimes within the same sprint — and avoiding the delays and wasted work associated with big-batch refactoring.
Why it matters
- Large, dedicated refactorings are hard to justify to stakeholders and often return benefits only after a lengthy delay.
- Incremental cleanup while implementing features produces immediate or near-term gains for ongoing work.
- Focusing refactoring where code is actively modified reduces wasted effort on areas that may not be revisited.
- A steady, local approach helps restore and sustain development velocity without major interruptions.
Key facts
- Projects often begin with clean code but gradually accumulate issues as features are added.
- The author equates accumulated problems to overgrown brush that slows future work.
- Requesting time for a big refactor is usually denied or yields limited results because it fixes past mistakes.
- A large refactor can take weeks and may not be allotted that much time by stakeholders.
- Incremental refactoring means cleaning the code paths used by the current feature rather than the entire codebase.
- Cleaning as you go can sometimes speed up the very feature that triggered the change.
- Repeated incremental cleanup compounds benefits, gradually restoring developer productivity.
- This approach avoids long delays and the risk of cleaning areas that won't be needed soon.
What to watch next
- Whether teams begin to propose refactoring as standalone backlog items or continue to do it as part of feature work.
- If product owners routinely reject large refactor requests, teams may shift toward the incremental approach described.
- Look for signs that incremental cleanup yields faster follow-on work and measurable velocity improvements.
Quick glossary
- Refactoring: The process of restructuring existing code to improve readability, maintainability, or performance without changing external behavior.
- Backlog: A prioritized list of work items, features, and fixes that a development team plans to address.
- Technical debt: A colloquial term for suboptimal or messy code and design decisions that make future changes harder.
- Sprint: A fixed-length development cycle, commonly used in agile methods, during which a set of work is completed.
Reader FAQ
Should refactoring be added to the backlog as a separate story?
The author recommends against treating refactoring as a standalone backlog item; instead, improve code incrementally while implementing features.
Why not schedule a big refactor to fix accumulated issues?
Large refactor sessions are difficult to get approved, take substantial time, and often delay benefits while risking wasted effort.
How quickly do incremental refactors pay off?
Sometimes benefits appear within the same sprint; generally they compound over subsequent feature work.
Is 'technical debt' actual debt that should be budgeted for?
The author argues it's more accurate to view it as deteriorated code quality rather than a literal debt; further financial framing is not confirmed in the source.
There has recently been a lot of noise on the lists, and questions at conferences, about putting refactoring "stories" on the backlog. Even if "technical debt" has grown up, this…
Sources
- Refactoring – Not on the Backlog (2014)
- Before you create your next “refactoring story”, read this
- Code cleanup / refactoring / touching code not related to …
- is it ok that development team create refactoring tasks in …
Related posts
- How Twitch Managed Standards Across a Million Lines of TypeScript
- Observability’s Past, Present, and Future: Origins, Failures, and Outlook
- How fast can text chunking get? Inside memchunk’s ultra-fast approach