Refactoring – Not on the Backlog (2014)
Key topics
Refactoring code without explicitly adding it to the backlog is a debated topic, with some arguing it's essential for maintainability and others seeing it as a luxury. The discussion ignites with the idea that every PR should leave the codebase cleaner than it found it, sparking a lively exchange between those who see this as a key to delivering maximum value to the company and those who view it as a "hobbyist's rule." As commenters weigh in, a consensus emerges that incremental cleanup is crucial, with one engineer sharing a successful "50/50" rule from their previous experience. Ultimately, the thread highlights the importance of code quality and the need for engineers to feel secure and invested in their work to drive positive change.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
30m
Peak period
10
0-1h
Avg / period
3.8
Based on 19 loaded comments
Key moments
- 01Story posted
Jan 5, 2026 at 2:23 PM EST
6d ago
Step 01 - 02First comment
Jan 5, 2026 at 2:53 PM EST
30m after posting
Step 02 - 03Peak activity
10 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 5, 2026 at 7:53 PM EST
5d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Refactoring – Not on the Backlog - https://news.ycombinator.com/item?id=27473133 - June 2021 (2 comments)
Refactoring – Not on the backlog - https://news.ycombinator.com/item?id=17624558 - July 2018 (1 comment)
Refactoring – Not on the backlog - https://news.ycombinator.com/item?id=8109065 - July 2014 (1 comment)
Having a maintainable codebase is of MASSIVE LONG-TERM value to a company - far too many orgs are paralyzed by mountains of tech debt.
Doing the minimal work possible is fine for 1-off hotfixes or tweaks or small features, but your argument assumes "maximum value to the company" is measured in the span of of a sprint, and it's not.
Cleaning up the codebase incrementally does deliver value to the company as long as you understand "cleaning up" as "making it easier and faster to contribute to, change, or debug in the future" rather than something adjacent to a form of performance art.
as professionals who are invested in the long term success of the company, it our responsibility to bring up concerns about the future, and attempt to negotiate a good compromise between the short term and long terms goals.
One thing not mentioned, is that it’s still incredibly slow. There will be a lot of time pressure and bad optics no matter your choice, this is a lose-lose situation without the proper support. The pressure can also make it difficult to not create new brush in the process.
a tale as old as time - my second job out of college back in like 2016, I landed at the tail end of a 3-month feature-freeze refactor project. was pitched to the CEO as 1-month, sprawled out to 3 months, still wasn't finished. Non-technical teams were pissed, technical teams were exhausted, all hope was lost. Ended up cutting a bunch of scope and slopping out a bunch of bugs anyway.
Though, one counter-argument in favor of putting refactoring tickets on the backlog is that it can be useful to make the cost of cleaning the codebase more visible to the higher-ups.
This is especially interesting if each sprint you organize to take up the feature tickets AND the refactoring tickets at the same time. If you work in a place that refuses to pick up the refactoring, then indeed the "hidden" approach described here is probably a good way to go.
It might seem that way, but it isn't.
A bad manager/boss pressuring the team to make the wrong decisions - yes, in that scenario the main problem is the boss.
Unfortunately, in my experience, there's often talk about one situation without the other (at least portrayed as the only one). Many times it feels like it's too divert blame and guilt, and to defend what is really the opposite situation. Really makes discussing this topic more toxic and a lot less valuable - much more interesting to discuss the nuances!
I learned this when a collage mentioning this to me. Turns out I was doing it without knowing it was a thing! Of course I continue doing it, but it's good to have a short and clear name to give others (specially those that only seem to follow concepts if they have a flashy name)
I attribute most of my success to following those rules.
And maybe I’m just applying my own biases, but all the best developers I’ve worked with seem to follow those rules as well.
Don't refactor anything bigger than a breadbox. Instead, colonize a new territory, and start a new map - with fewer thickets, one hopes. In my experience, this is possible. It's hard, but it's possible. What's good in the old system survives, all the rest atrophies and dies, and new rails carry the project forward.
But, one assumes, you have a running system and you need to keep it running. If not, knock yourself out cleaning up the map. It can't do any harm.
Such a shift isn't easy to achieve, but it is possible. Don't just clean-up. Extend what you can, rebuild what you must, strangle what's left. Don't half-ass it. Product group's sanctioned refactoring is half-assing it. Your responsibility is to the product itself.
In an academic sense this will be a failure, but practically, with a living-system organism you'd like to keep alive, it can work.
Spoiler: AI isn't going to help with any of that. I'm expecting a 'second winter of horrible codebases' (the first winter being when big companies discovered outsourcing)
Happy to see these "fundamentals" being still spread around
Not sure "refactor in context" is the tool for every single last refactoring job in the universe. Some plumbing changes may be large or systematic enough that they need to be separately planned and applied, especially as explaining "oh I changed the fundamental way we do things, just in passing" can be a hard PR to present. OTOH, since adopting the "in context" approach I have had many fewer refactoring attempts abandoned, and refactoring seems much more logical and purposeful. So it works IME.