January 5, 2026
Weed whackers vs feature trackers
Refactoring – Not on the Backlog (2014)
Refactor fights: clean-as-you-go vs “put it on the list”
TLDR: The article says skip big cleanup projects and instead tidy code while adding features. Comments split between “leave every change cleaner,” “log refactoring tasks so bosses see the cost,” and one hot take predicting a new era of messy code—AI won’t save us—making this a debate about craft vs visibility.
A 2014 essay resurfaced with a spicy message: don’t schedule big refactoring cleanups—just tidy the code while building each feature, like cutting a path through weeds instead of planning a landscaping weekend. Cue the crowd. dang rolled in with receipts, linking past debates that keep coming back from the dead (HN thread).
The loudest cheer came from 0xblacklight, dropping the campsite rule: “every PR should leave the codebase cleaner”—PR means a pull request, basically a change request to the code. Fans loved the simplicity. But move-on-by poured cold water, saying it’s obvious yet hard, and still incredibly slow without strong tests and a dedicated team. Translation: it’s not just a weed-whacker, it’s a whole gardening crew.
Then came the boardroom angle. ds-rants argued that putting refactoring tickets on the backlog—the team’s to-do list—can make the cleanup cost visible to higher-ups. Managers love charts, not invisible elbow grease. And A_Duck lit the match: good code needs secure engineers with time and ownership, not magic tools—“AI isn’t going to help,” and they predict a “second winter of horrible codebases.” Ouch.
Result: a three-way drama—garden-as-you-go purists, visibility-first realists, and doom prophets warning an AI-fueled mess. Popcorn secured.
Key Points
- •The article argues against placing refactoring stories on the backlog.
- •It describes how rushing feature development accumulates poor code that slows progress.
- •Requesting large refactoring blocks is often denied and, if granted, yields limited, delayed benefits.
- •It recommends incremental refactoring: clean the code only where current feature work occurs.
- •This approach delivers immediate and compounding benefits, often within the same sprint.