I like this. It seems obvious, but I’ve seen many different teams struggle with it. There is a lot of difficulty clearing the brush in a way that doesn’t break existing paths and is also repeatable. It takes a team with a vision and dedication to pull it off correctly, not to mention robust tests to ensure reliability.
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.
I largely subscribe to what is described here, and believe sincerely that any piece of work should be an opportunity to do a little bit of cleanup.
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.
The way to ensure good code quality is: have engineers who are secure in their jobs to push back, who get time to develop and benefit from a good reputation, and who feel a strong ownership of the code
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)
This seems very consistent with the refactoring techniques taught by Sandi Metz (https://sandimetz.com/99bottles). After taking her course, I successfully applied those techniques to good ends and outcomes.
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.
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.
I've seen so many engineering teams present bad options, on the implicit assumption that the responsibility for choosing the worst/cheapest option is on the decision-maker. And if they are pressured to deliver bad code, an email trail showing that it was the boss's fault will save them.
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)
12 comments
[ 2.6 ms ] story [ 30.5 ms ] threadRefactoring – 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)
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.
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.
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)
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.
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.
It might seem that way, but it isn't.
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)
Happy to see these "fundamentals" being still spread around
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.