Peter Morlion logo

Blog

When Not to Refactor

There are cases where it makes sense not to touch a legacy codebase with lots of technical debt. Unlike real debt that must always be repaid, technical debt doesn’t always need to be. But the use cases are more exception than rule.

No Need For Change

A piece of software that runs fine without the need for any change can be left to run just fine. If there are no (blocking) bugs, there is still support for the platform, maybe you’re monitoring it closely and all is OK, then you have little business reason to touch it.

In fact, touching it might make the situation worse than before. Especially if an enthusiastic dev team wants to make a major overhaul.

Phasing Out

Another case where it no longer makes sense to refactor a project is when you know it’s going to be decommissioned soon. Of course, this also assumes it’s running fine, without major issues.

Let’s say you have a website running on a custom CMS that is a technical mess. But you’re planning to create a new website using WordPress next year. In such a case, it doesn’t make sense pouring time and money into anything non-blocking.

Even if you have reason for a change, it might be better to invest your money into the new project and apply the change there.

Personal Preference

As a last case, I’d like to mention personal preference. Liking or disliking something alone isn’t enough reason to refactor or rewrite software. If your lead developer hates PHP, but an important, money-generating project runs on it, then the lead developer will have to adjust. Unless they can provide compelling reason to change.

Technical debt doesn't always need to be repaid

In fact, it’s a crucial characteristic of a senior software developer that the programming language and libraries matter less to them. Of course, everyone has their favorites, but if we’re talking about company money and time, professionals can set their preferences aside.

Is It Worth the Risk?

There are cases where refactoring is a bad idea, but they are quite rare. The reason I laid out above will also come into play in situations where it is a good idea to refactor or rewrite. But in those cases, there will also be other, more rational reasons to do so. However, if one of these three is the only reason, then it’s not enough to take the risk.

Leave a Reply

Your email address will not be published. Required fields are marked *