How to talk about refactoring
There’s one serious problem when talking with managers about refactoring. Many people tend to call a task or a project refactoring when in fact they shouldn’t because it implies it’s going to take a fixed amount of time. It has a beginning and an end, meanwhile refactoring shouldn’t never stop, it’s an on-going activity. Thus, we should never use that key word during conversations with managers.
It is far better to call it paying tech debt, stabilization, improving static testing, improving architecture, improving Developer Experience, etc., because those are actions, which could have a fixed scope, thus - take a fixed amount of time.
If you think naming or wording doesn’t matter, you could never be more wrong! It’s easier to be understood by managers if you use appropriate terminology; and what’s even more important - it doesn’t limit developers. By not talking about refactoring separately, we assume - correctly - that refactoring is just an integral part of a task or a project. And since it’s an integral part, there’s no reason to invite your manager to micro-manage you.
I’m not saying you should now spend twice as much time on a task, because you’re doing refactoring. It’s a matter of proper prioritization. Remember, any project should be “good enough, fast enough, cheap enough, and done as much as necessary” [Clean Agile]. Keeping the right balance is crucial. You can refer to The Boy Scout Rule - Leave the campground cleaner than you found it. Make projects a little bit better every single day.
Moreover, “it’s unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes” [Clean Code]. So, be determined, negotiate if necessary and don’t give up quickly. Remember, “developers have the right to produce high-quality work at all times” [Clean Agile], so no one should be allowed to ruin your professional reputation or violate your professional ethics. No one would ask a doctor to treat patients only a little, or a lawyer to defend a client just a bit, right?
If you find it hard to convince your manager that improvements to the code base are necessary, let me refer you to my another post: How to talk about Tech Debt.
Last but not least, remember - Dirty always means slow.