A few days ago my teammates and I completed a large refactoring project. We’ve spent several weeks on it and achieved excellent results. Our codebase is now simpler, more maintainable and flexible. It has no dead code, and the test suit is now faster. Everything went well. Even better than we planned.

That inspired me to share some tips on how to avoid troubles in refactoring projects and successfully complete them on time.

In this post I’d like to talk about refactoring "scope creep".

Scope creep happens when developers keep on uncontrollably adopting tasks at any stage of project. Typically, these tasks are unrelated and the reason they are done is often just one developer’s personal preference.

As a result, dev time is spent on minor refinements that don’t lead to any big improvement in the product neither from technical, nor from business perspective. In other words, developers invest their time without getting much return to justify their efforts.

This is not the worst problem that may happen during a refactoring project. It is fine to give developers some time to improve the code where they think it is necessary to feel happier especially if it doesn’t take much time or happens when they don’t have much feature work.

However, it doesn’t hurt to be more strategic about any initiative, including refactoring, that is happening on the product. In particular, that means two things:

  • understanding the goal of the initiative,
  • working only on tasks that help achieving that goal, in the order of their importance.

1. Set a Goal

In case of refactoring that means that developers should define the goal they would like to achieve before changing any code. A good refactoring goal is often linked to the important upcoming features in the product roadmap.

With the refactoring goal in mind, it is easier for developers to tell which improvements are worth the required efforts and which are not. It is also much harder to pick tasks that are not helping to achieve a known goal.

2. Make a Plan

The second most important thing after defining the goal is to put together a detailed plan to achieve it. Even though the plan is likely to be updated multiple times as a large refactoring goes on (developers acquire more knowledge in the process), it is still important to have it before the code gets modified.

3. Stick to the Plan

The next important thing is to stick to the current plan. If you feel that you have to work on something that is not in the plan, talk to your teammates first. Together you can evaluate the task and decide if the plan should be amended or the task should be parked.

Example: for a product with legacy front-end built in coffeescript, jQuery, Backbone, and React (true story) a refactoring goal could be to migrate functionality built with coffeescript, jQuery and Backbone to the latest version of React to prepare the product for UI redesign. Having a goal, it is easier for developers to resist the temptation to refactor easy but irrelevant parts of the codebase and focus on tasks that bring them closer to the goal.

Compare achieving that goal with spending the same efforts on tasks like upgrading the version of jQuery and Backbone, getting rid of only coffeescript, writing a couple of missing specs, tweaking CSS that is used by UI built in those frameworks. All that variety of these improvements probably doesn’t sound as exciting as having only one front-end technology.

4. Time-box the Refactoring Project

Another good idea to prevent scope creep may be to time-box entire refactoring project. When people know they have only certain amount of time (like 3 weeks, or 5 days) to spend on something, they usually tend to spend it wisely. Which in case of refactoring means spending it on the most important tasks.

If developers really want to adopt a task in a time-boxed project, they have to remove another one from the plan to avoid scope creep.

Summary

To sum up, to avoid scope creep in refactoring project:

  • ensure every developer understand the goal of a refactoring project,
  • make a detailed plan to achieve that goal,
  • stick to the plan,
  • review the plan only when discover work you can’t avoid to achieve the goal,
  • time-box refactoring project,
  • when adopting a task, remove another one from the plan.

Thanks for reading this!