Refactor Like a Superhero

Introduction

Refactoring requires resources. The amount of these resources depends on the size of the project and its code quality. The larger the project and the worse the code, the more difficult it is to clean it up and the more resources it may require.

To justify the investment of resources and find a balance between costs and benefits, we need to understand the benefits and limitations of refactoring.

Benefits for Developers

Code quality is an investment in developers’ free time in the future. The simpler and cleaner the code is, the less time we’ll spend fixing bugs and developing new features.

Developers may care about different properties of the code. For example, we might want to:

• Find code related to specific parts of the application faster.
• Eliminate misunderstanding about how the code works and avoid miscommunication and conflicts in the team.
• Make it easier to review code and check it against business requirements.
• Painlessly add, change, and delete code without regressions.
• Reduce the time to find and fix bugs and make debugging process more convenient.
• Simplify project exploration for new developers.

This list is incomplete. Other properties may be necessary to a particular team, varying from project to project.

Regular refactoring helps pay attention to code properties before problems appear. It makes daily work more efficient, gives developers extra time and resources, and prevents “big refactorings” in the future.

Benefits for Business

In a perfectly organized development process, there’s no need to “sell” refactoring to the business. In such projects, regular code improvement is at the core of the development, and bad code does not accumulate—no need to “explain the benefits to the business” in this case.

However, there are projects where development is organized differently for various reasons. In such projects, as a rule, legacy code tends to accumulate.

We may feel the need to improve the code, but we may not have enough resources to do that. A proposal to “take a week to refactor” might cause a conflict of interests because, to the business, it sounds like “we’ll do nothing useful for a week.” These are the cases where we may need to “sell” the ideas of the code improvement.

The benefits of refactoring aren’t evident to the business because they aren’t immediate. We may see them in the future, but it’s difficult to predict when.

Usually, to sell the idea of refactoring to business, we should speak the business language, and sell the result, not the process. Discuss what exactly we’ll get as a result of the time spent:

• We’ll spend less time fixing bugs, so the number of unhappy users will drop.
• We’ll start implementing new features before our competitors, so they generate new users and profit.
• We’ll better understand the requirements and constraints, so we react to unpredicted problems faster.
• We’ll make onboarding easier for new developers to make significant changes sooner.
• We’ll decrease staff turnover because developers don’t run away from good code, only from the bad one.

We can use various metrics to measure code quality. It’ll be much easier to determine the necessity of refactoring by relying on the numbers. For example, the costs statistics might help to incorporate regular refactoring into the development process smoothly.