Developers are always looking for ways to improve their codebase. We track tech debt and attempt to priorize this work while not disrupting projects and ongoing business objectives. In order to avoid the proverbial foot-gun, there are some things that we should consider before we take on large initiatives to refactor existing code.
Timing a change
When considering refactoring a certain piece of code or module, it is important to be aware of the ongoing work in other teams, projects, or development efforts within your organization. To make effective use of time, and to make it easier for others as well as ourselves, we should avoid drastically changing or merging code that is already actively being worked on.
If we are not careful in this respect, we may end up writing a bunch of new code that either becomes irrelevant, or needs to be refactored (again) if other changes took place at the same time that have signicant impact on the new implementation. Also consider that if we refactor some code from under another team or project, it may end up inadvertently slowing down their work, and having a negative impact on business outcomes, leaving no one happy in the end.
So if we are planning a big change, and are not sure whether it might impact others, play it safe and ask the relevant teams or individuals that own that part of the codebase!
Considering implications of change
When refactoring sometimes we can become blind to our product or engineering roadmap, and end up focusing solely on the technical outcomes. Be aware of what effect the changes might have on future initiatives:
- Are you removing potential paths for a project?
- Is your new implementation easy to extend?
- Are you making decisions now that will have implications on future plans?
Considering if a change can be broken down into smaller changes
To help us plan a refactor and understand the goal of the changes, we should aim to make changes in iterations. Breaking down work can help create something more structured, as well as allow others to adjust to the new pattern progressively instead of one large merge conflict that may completely blow up their scope.
Breaking the work down can also help facilitate the messaging and conversations around refactoring by creating milestones where we can communicate to the team and inform them that the work will be merged. Over-communication is key for changes to patterns, models, or structures. Allowing time for teammates to understand and question the new code before completely shifting from the old will result in better outcomes for everyone.
Was this helpful?
