[ehnto]

It often is a task of it's own. It's not always "low-level work", sometimes it's directly replacing key components in a huge chain of events that all need to be modified to accept your refactor. It really depends on the codebase, features you're developing, nature of the business engagement and so on. There is also risk in a refactor, especially if it's heavy in business logic.

If I'm doing a bugfix task on a legacy site, I might note that it would be good to spend ~4h on a refactor, when the bug may have taken 0.25h to fix. In that scenario the benefits for refactoring are low, so we don't do it.

Alternatively, if I'm doing a 6h feature, and understanding and working with the bad code would take 6h, versus spending 4-6h on a wholesale rewrite, of course I would just slip the refactor inside the original task.

You have to keep your expectations realistic and your project managers informed. If your refactor suddenly blows out in time because you didn't fully comprehend your problem space, then you both haven't completed the feature or achieved the refactor. Maybe in your business a day extra is fine, in some businesses running over by a couple of hours can mean the ROI doesn't make sense on that task anymore.

The key is to be sensible and pragmatic. There is no one solution to all thinking. If there's anything any of these methodologies are trying to do, it's provide a framework for quickly communicating and reacting to the nuance of software development.

[user5994461]

>>> It often is a task of it's own. It's not always "low-level work", sometimes it's directly replacing key components in a huge chain of events that all need to be modified to accept your refactor. It really depends on the codebase, features you're developing, nature of the business engagement and so on. There is also risk in a refactor, especially if it's heavy in business logic.

And that's why refactoring has a terrible reputation and developers can't be trusted. Now you're talking about replacing key components and altering the business logic under the pretext of refactoring.

This should NOT be called refactoring, this should be called replacing key components and revisiting the business logic.

Of course, management doesn't want that to be done without justification.

[watwut]

Refactoring may change how business logic works internally without changing anything in input/output or features. If you need to change how key components are implemented, without changing what they do, then you are refactoring them. Changes may be big internally, but it is still called refactoring if features don't change.

[adrianN]

If your code developed a "god class" that does everything and should be ripped apart there isn't much you can do about it except changing core parts of your project.

[ehnto]

I don't mean changing business logic, refactors have to retain business logic still, and the risk is that the developer gets that wrong.

It sounds like you're not getting good communication from your developers or you're misunderstanding them when they say they need to refactor. Refactor is still the right word for it, but you need to find a way to communicate the extent of the refactor.