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.
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.
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.
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 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?
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.
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."
If you come across technical debt and want to make it visible, use Stepsize VSCode or JetBrains extensions. It's a good way to start bookmarking your code, creating TODOs and issues, and prioritising refactoring and maintenance work.
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 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:
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.