I have coworkers who spend 90% of their time refactoring code. They are actually good programmers with great salaries and their refactors are 99% of the time an actual improvement to the codebase, but that's all the value they add and I have no idea how they're able to convince their managers to spent so much money just marginally improving things that were previously working.
Personally I like when code gets defactored*. Defactoring removes undocumented abstractions, call proxying, dynamic dispatch, higher order args, boolean args, utility source files, etc, to a reasonable extent. Code wtfness is its total length x complexity^2 / documentation. Successful defactoring leaves you with less wtfness for a reasonable amount of time.
Re-factoring may increase (in-/en-) or decrease (de-) it. If it becomes self-opinionated, buggy and slows you down, that likely increased. Textbook refactoring usually trades amortized length for complexity, not the other way round, but that’s okay because they take it from a “completely flat code” perspective.
So it really depends on your coeffs in that formula and ideally should be managed by someone who tracks these indicators. Not by a passer-by whose taste was offended that day.
* google has some definitions, but I used the term freely
I like the breakdown and agree with your general line of reasoning.
I’m confuse though why you don’t just say refactor. This just reads like you redefined “refactor” to be adding layers and “defactor” to removing layers.
Textbook refactoring, changing a program internally without changing it external. It’s up to the refactorer to choose what to apply.
Applying a refactor is not only adding FactorBeanProxies. It can, and must be, used to remove parts as often as adding them.
If your coworker is refactoring code and making it buggy and also making it harder for the rest of the team to understand, that might be a bit of a problem. When working in a team, you follow common conventions you agree on for a reason.
Rebuilding something for the sake of making it say 5% cleaner is often a bad business decision. No matter how well you think you're testing something, any non-trivial system is going to have some edge cases and crazy things that messing around with is going to cause you headaches.
But if a system is a complete fustercluck and long-term progress is harmed with how convoluted it is, then spending a lot of time refactoring it seems wise.
A good engineer has the judgement to know when tinkering with existing code is the smart thing to do.
I wonder where the line between improving the product and "I don't like this abstraction so I'm going to rework it to something else that I like" is...
I once had a coworker who would love to refactor his code that he badly wrote in the first place. He did well at the organization, creating problems and then solving them magnificently.
