If you mean larger refactors, then it is discussed in hushed or hopeless tones at most places I've worked. There are reasons it is avoided on both business and technical sides. Business gets no tangible value (no new features) and extra risk that the refactor breaks something. From the dev side, familiarity can sometimes be strong inertia in a team setting. This is all made worse by the fact that refactors frequently turn into explorations of new tech/patterns. They don't improve things so much move the technical debt to a different area. I have made this mistake more than once.
Refactors like that are investments in the future of a product. So they should be planned in detail -- usually there are a lot of details to untangle. The practical benefits AND downsides should be researched. It shouldn't just be a tech swap. Breaking it down into smaller, incremental improvements is best.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you mean larger refactors, then it is discussed in hushed or hopeless tones at most places I've worked. There are reasons it is avoided on both business and technical sides. Business gets no tangible value (no new features) and extra risk that the refactor breaks something. From the dev side, familiarity can sometimes be strong inertia in a team setting. This is all made worse by the fact that refactors frequently turn into explorations of new tech/patterns. They don't improve things so much move the technical debt to a different area. I have made this mistake more than once.
Refactors like that are investments in the future of a product. So they should be planned in detail -- usually there are a lot of details to untangle. The practical benefits AND downsides should be researched. It shouldn't just be a tech swap. Breaking it down into smaller, incremental improvements is best.