Ask HN: How to inform management about much needed refactors

So what's the business case? The fact that you hate the current code is not. As a manager (and a developer) I'd be very wary of letting a new employee refactor a project that they are unable to work with. If they cannot work with it do they understand what it does? Do they understand future plans of the company? Will their refactor be objectively an improvement? Will they even finish the refactor? Doing a major refactor is a major risk. I was involved in a couple of refactors that only resulted in a different mess. If you want to convince me to do a refactor I need a strong case that will answer all the doubts.

Sorry if I came across as harsh :)

Give a little and get a little. Tell them that the code really has served well until now but it has grown to a point now that it is like an avalanche of issues and you are convinced it won't support too many more features and changes. Then give them a few updates of the easier features in turn for letting you redo a section of code, and keep moving it forward that way.

To this exact point. I recently have been involved with a company in a consulting gig. The reality is they need to just shit can their code base and start over. The fact is they can't do that, so we are adding features to their code base while we are also revising it in significant ways. We were just very up front and said that we cannot guarantee the changes at this point because the code is extremely fragile.

Also, part of what helped sell them at least, was my discussion that hey, what worked a couple of years ago was great, but today it isn't serving the needs of the clients so we have to rethink what is being done. Not saying they prior team was bad or incapable, regardless of my personal feelings. Maybe the same will help you.

Do you mean refactor or rewrite? If you actually mean rewrite, then get a better plan. Figure out how to proceed with a phased refactor based approach. Fold the refactoring into new features.

Learn to speak in terms that the deciders understand. Speak in terms of FTE hours (cost) and reliability (risk). Speak in terms of What you're doing, not How. When you speak in terms of how, you're just inviting people to micromanage you. They really want to know how many FTE hours doing something is going to take, and how much risk they are exposed to. How you accomplish it is up to you.

If you tell them that next feature will take a year (because you're going to rewrite everything 1st), then they'll probably tell you to take a hike. So, you'll have to figure out how much refactoring you can do with each added feature to still make them happy.

Finally, you can't care more about the problem than the customer (in this case, your employer). You should care about your work, but don't put yourself in the position where you're more emotionally attached than the owner.

This will always be a constant battle. Management wants new features asap and developers want to make the code base better. I've been there many times.

Just be honest. You will have to show them why it's a problem, you can't just tell them. Add new features onto the code base and show them how long it will actually take you.

I'm not sure it's even possible to sell a good percentage of managers on the needs of a refactor no matter how good your arguments are. Many of them either don't have the technical chops to even understand the need for major refactorings (no matter how much you "educate" them), or consider the technical debt accumulation an acceptable risk vs a perceived low ROI with refactoring.

My advice: Don't tell them unless you think you have to rewrite the whole thing or huge chunks of it. Refactor as you go, and adjust your estimates accordingly.