You just hired a bunch of superstars who are in tune with the latest industry trends. They roll up their sleeves and get to work. In a few days, they point out some systematic issues in your codebase that is making it difficult to expand current capabilities, and chalk out a plan for significant refactoring. But there’s a caveat - the refactor work will be a blocking issue for your near future roadmap. You take a look at your service and gather that things have been working smoothly, with minimal disruption, but you also realize that further innovations to your service is difficult and that is the problem that the refactor can potentially solve. But before you pull out all the stops and go into refactoring mode, here are a few things you need to consider.

Get proof that the refactor will work

Before even delving into the execution, you may need proof that the refactor works. You will also need to plan for adequate test coverage and a solid a QA plan. Is the functionality needed in the new version clearly documented? The reasoning for the refactoring needs to be kept as simple as possible - why will the refactor make your system better and improve the chances at achieving the roadmap and not just that it makes it more “in line with industry”.

💡
What is ping test?Learn how to ping in Windows here.

Can it be done incrementally?

Ask your team - what is the smallest productive part of the refactor that we can get started with. Can we break the refactor into several milestones and migrate over piece by piece? There might be resistance to this, ie stating that it will be way simpler to do it all in one go. But you must insist on a plan that gives you clearly defined short term deliverables which would then be followed by well defined milestones. The proposal for the refactor needs to be scoped out with the same level of rigor as a brand new project. Do not underestimate the level of effort. Ask your team to write up a one pager proposal and have the rest of the team vet it. Also consider - what will be the plan if this does not work out as well as they think it would?

📑
Discover about major incident management and its techniques here

Business-first approaches

You can also look at reordering the roadmap based on the refactoring effort. This way, each incremental milestone in the refactoring excercise leads to a feature that the business wants. If this is also done in a manner where you are able to work in the order of the new features that the business wants, then it can become a win-win for everyone. You can also take the feature and ask if there is a way to re-design how the proposed feature would work without having to refactor the current system and then compare the trade-offs involved. A lot of engineers have an idealistic picture in their minds and rarely conceptualize alternate approaches, and therefore pushing for specific alternate approaches per technical problem might serve you well.

A lot of engineers think the “all or none” approach is the only option when it isn’t and while they’re all trying to do best by the team and company, at the end of the day, you should always look at refactoring as an opportunity rather than an obstacle.

Looking for an end-to-end incident alerting, on-call scheduling and response orchestration platform?

Sign up for a 14-day free trial of Zenduty. No CC required. Implement modern incident response and SRE best practices within your production operations and provide industry-leading SLAs to your customers.