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.
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)
I learned this when a coworker mentioned 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.
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.
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)
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!
GitHub Discussion: “Feedback: tell me when it interrupts you”
There’s no analytics or tracking. Just paste the output of a local telemetry_report (anonymous, local-only).
I’m mostly interested in when people override the guardrail and why.
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.
Happy to see these "fundamentals" being still spread around
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.
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.
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.
