Two words combined in a phrase will awake the most profound fears in CTOs, Project Managers and Tech leads: “code refactoring.”
“If you want to build X, we need to refactor the code.” Of course, the natural question to ask is “how long is it going to take?” Don’t believe the answers. No one knows. I’ve been involved in the software industry since 1999, and I haven’t seen anyone that could provide an accurate estimate.
The reason? It can take from 15 minutes to 15 months. There is a fine line between code refactoring and rebuilding the app, plus the reverse engineering time you need if the developers aren’t familiar with the codebase.
Code refactoring is a sunk cost, is a tech debt, is something you can pay in full, or in several payments.
I understand that you as a tech lead you want to avoid code refactoring as much as possible. You can’t. And the longer you wait, the more expensive it becomes.
So, when is it a good time for a code refactor? Anytime is good, if you can afford it. What you need to do is to set boundaries, a specific area of the code, and in a particular timeline, no more, no less. Ask your developers to stay focused, and whatever can’t be refactored within those boundaries, it should not be refactored.
If you can’t break down a class because of dependencies, break down the file. If you can’t break down the file, break down the folders. Go up in the hierarchy. It is not about optimizing the code, that’s a different kind of work. It is about organizing the code, so next time you need to build a feature you spend less time on it (code refactoring ROI.)
Do you want to reduce the code refactoring costs? Hire good developers.
