When Should I Refactor Code and How to Get Buy-in for Refactoring?

As you push forward to create and ship the next big thing to market, you've probably let some things slide that just might now be catching up with you. One of these is refactoring - the process of changing a software system so that it does not alter the code's external behaviour yet improves its internal structure.

Let's take a look at when you should consider refactoring your codebase and how to convince your management to spend time on refactoring and technical debt.

What's your workplace culture when it comes to refactoring?

Deciding when to refactor code depends in the first instance on workplace culture. In an ideal world, code is refactored little and often, meaning that it's a task that is integrated into everyday work tasks. Having a baseline of regular refactoring means that any deeper code refactoring is typically less onerous.

Comparatively, if it's a task that's been low on the things-to-do list, or was the responsibility of someone who's too busy or left the organisation, then it can be a tough sell. In such a scenario, making code refactoring a priority means either hiring extra staff or pulling away staff from other tasks. It can be hard to convince management to put other jobs on hold to focus on refactoring.

When code refactoring needs to become a top priority?

Devs team is slowing down

This is probably the easiest way to convince devs and management to prioritise code refactoring as it has both a technical and business impact. You may be in a situation where your poor quality codebase means adding features and bug fixing become impossible. It may be a situation of legacy code, design or architecture issues or where code is no longer serving its original aim.

As Dan Goslen shares,

"Ever had a moment in your software career where you needed to make a simple change, but found it hard to implement? The code was so fragile you couldn't make your change without breakout myriads of tests? Or maybe it was a time when you couldn't understand what caused a production problem while looking at the source. You couldn't understand which code was executed or where to start. Logs and metrics couldn't help either."

In such scenarios, developers are being bottlenecked and slowed down by a lack of refactoring.

It's been a while between commits

Admittedly less of an issue for those embracing DevOps with little and often commits; if it's been a while since commits, it's likely your code needs updating and refactoring before you can move forward with it.

You work on your own

You love escaping the banal watercooler chats, but working alone means you might not have other devs regularly reviewing code, offering fresh perspectives, edits and refactoring commits. Lack of feedback makes it easy to put off refactoring. Might it be time to chat with other solo devs to collaborate in some capacity for shared benefits?

You work with lots of legacy code 

Ok, you might not be in a bank or government office working with COBOL, but you might have inherited a legacy codebase that needs updating and untangling before you can add new features or fix bugs. If you are teaching yourself how it all works, it's a great time to make notes on any refactoring needed and create a plan to bring it up to speed at the same time.

Technical debt is becoming something you can't ignore

A lack of code refactoring may have led to an even bigger program that's now costing your organisation both time and money in terms of developer frustration and delays technical debt. As Johnny notes, 

"Without enough care to create proper abstractions while writing new modules or features, technical debt can accrue rapidly. In agile-oriented teams that move and iterate quickly, the fallout from accumulative technical debt can occur with negative consequences sooner rather than later."

How to deal with technical issues best?

If you’re looking for a sustainable solution for tech debt management in your engineering team, you need Stepsize. It’s the world’s first and only bespoke tech debt management tool. Track and manage issues directly from the IDE, and create issues directly linked to code. For engineers, this means no more context-switching and high-quality issues that can be prioritised based on impact and fixed. And because it integrates with Jira, your PM will love it too.

‍Learn how to get started with Stepsize here. It works with Visual Studio, VS Code, JetBrains.

The challenges of refactoring 

Let's face it, there's plenty of challenges with refactoring, especially if there's a big backlog and a team of people less inclined. You not only need to get on top of it but create a workflow where it's unable to reach mammoth proportions ever again. 

Further, effective refactoring requires developers with enough skill to fix whatever ails. No one wants to risk breaking code, and any unintended changes to complex functions make it hard to manage and unit test.

The elephant in the room: should I just rewrite instead of refactoring?

The idea of starting from scratch is hugely appealing to many, especially if your needs have shifted massively from an old codebase. Nicholas Tietz-Sokolsky at Remesh provides an excellent case study of where rewriting makes sense for many reasons. Firstly, the company started small with low velocity and lots of product bugs. He notes:

"The problems were largely our codebase and our process. The legacy codebase we were working in was ill-suited to both the skill set of our team and to the problems we were solving, and our process encouraged and relied on siloed knowledge: there was no "full-stack" at Remesh."

Other problems they had:

• They designed their legacy application for something very different from its current product-market fit and use case. Thus certain old design decisions no longer made sense, and the schema needed major changes. 
• Their codebase included bolted features. This meant not refactoring and poor test practice, especially in older code. 
• Remesh devs wrote code in languages and frameworks that were either out of data or not known well by developers. 
  

As Rotate notes, ​​rewriting is a massive undertaking involving lots of time, skill and resources. The original code needs to be maintained until you can integrate the brand new code into a project. Nicholas notes for those wondering if they should rewrite instead of refactoring:

"Based on my experience here, you probably… shouldn't, if you buy the hype that rewriting is never the right decision. At any rate, you should default to the "no" position and then work very, very hard to justify it if it's necessary."

There are loads of great reasons to refactor. Clean code is easier to maintain and expand upon and add new features. It removes duplicate code and streamlines development. Bugs are easier to find. Refactoring can result in more stable features, greater security in your applications, and a more streamlined development process.

Additional resources

• Ashish Jha offers a great example of actionable steps to complete when refactoring. 
• Love maths? Take a look at why refactoring is like an axe welding harvester harvesting trees. 
• Here is how to make the business case for technical debt.