Oh no! Yet another refactor request!
Oh dear, just what I needed… another delightful request for a refactor!
You can bet this is the first—and probably the second—thought that crosses the mind of any manager or engineering lead when some dev pops up with a shiny refactor idea during any brainstorming or planning session. It’s like, “Oh great, here we go again!”
That’s because there are few—like, really few—valid reasons for something to deserve a refactor.
But hey, that’s a topic for another post!
Anyway, getting management to understand that you need a significant amount of time for a meaningful code refactor is quite hard.
It’s basically a negotiation, so having your homework done is key.
Despite what you think, for the company, initiating a refactor is seen as a risky move that takes time away from - literally - any other activity.
And let’s be honest, it usually involves something that actually works—albeit in a messy, ugly, and barely maintainable way. But hey, after a lot of patches, it still delivers the goods!
It’s like trying to convince someone to fix a leaky sink when the water is still flowing.
You know it’ll be better in the long run, but getting buy-in is no walk in the park!
Who do you talk to?
Your primary goal is to make your needs align with the person you’re talking to.
Speaking the same language is crucial: for instance, someone who isn’t very technical won’t care much about the benefits of clean code, but they will likely be interested in how performance will change as a result of this activity.
Use concrete examples to explain how the current codebase is holding the team back, how refactoring can improve the status quo, and when applicable translate the benefits to hours or money.
The yourney so far
One of the big questions non technical execs have is “why did the codebase end up in this state in the first place”. Depending on who your audience is it may be important to have this information in your presentation.
Knowing what led to the current situation (when possible) shows a deep understanding of the problem and boosts your reliability in activities that can help set things straight.
Something like that adds context and justification that a non technical execs will understand.
The Evidencies
Refactoring should be treated just like any other project. Don’t just stop at chit-chat: if you can, strengthen your case with some solid data. Metrics, benchmarks, user feedback, and even downtimes are just a few nuggets you can pull out to showcase the potential benefits of a refactor.
The more evidence of possible improvements you have, the better you can paint the picture of why refactor is crucial (ROI / Return Of Investment).
It’s all about making your argument as bulletproof as possible!
After all, numbers don’t lie, and they can help turn skeptics into supporters.
Be sure to show how the benefits of the change.
- How will reduce security risk leading to a possible litigation
- How many hours will be saved on future development
The Plan
Make sure you have a rough plan. Of course, you won’t stick to it perfectly, but that’s okay because:
- It’ll help your conversation partner grasp the effort involved; especially for those who aren’t technical, it’ll make it easier to understand the scope of the work.
- It’ll allow you to really get a handle on the problem, forcing you to break it down into smaller tasks, which makes it easier to delegate to the team.
When you can show the problem and make a detailed plan to solve it, it’s hard to get no as an answer.
Anyway, the best way to avoid huge refactoring is to make refactoring part of your daily/sprint routine.
One step at time
A big refactor isn’t something you can whip up in a day, and management might need some time to wrap their heads around it.
Stay patient, keep pushing, and make sure to keep the communication flowing!