How to determine if a module within an application is worth refactoring or rewriting?

Question

We all know Joel Spolsky's famous article to never rewrite working code.

How about if we don't consider overall program but a module within? Module can be e.g.:

• payment handling microservice in e-commerce application
• data access layer (inline SQL to ORM)
• front-end layer (MVC to Angular)

Are there circumstances that justifies a module's (not full program or system) rewrite?

Answer 1

The rule, if there were one that made sense, would not be different for modules than for any other unit of code. After all every piece of code is a module, that is just semantics and perspective.

In any situation there may be several reasons for rewriting and for leaving it the way it is. What you should do solely depends on the weight you assign to those reasons. This all depends on your environment. Things to consider could be:

Pro

• Bugs keep popping up in that part, is has proved to be expensive to maintain.
• The platform the code was written in is running out of support.
• We no longer can find developers with the skills needed to do maintenance or willing to invest their time in this dead end technology.
• I need to learn this new language anyway, I will be using it a lot. I can do with some practice in an environment I know, I can start easy.

Con

• This system will be replaced in x years.
• The product is dead, it is no longer making money so it is not worth the trouble.
• We have far more important things to do with our time at the moment.
• We hardly ever have any trouble with it.
• We do not fully understand what it does and there is no documentation or test so we will likely break the functionality if we touch it.

And you go with whatever applies.

Answer 2

Yes, there can be reasons to do a full rewrite of a module. The primary reason would be that the way that the module is supposed to deliver its functionality must change very radically.

Then you can think of switching your data access layer from using a SQL database to a no-SQL database or from flat-file storage to a database.

Or the front-end could go from a browser-based UI to a native UI in a different programming language (or vice-versa).

Answer 3

The economic arguments for or against a rewrite of a module are mainly the same as the ones for or against the rewrite of a whole system, as they were already presented in the top answer to the question "When is a BIG Rewrite the answer?". In short, this boils down to a cost-benefit analysis, which depends on the specific piece of software and the requirements for changing it - so there is no general answer for this.

Of course, there are some differences to consider when planning a rewrite for a single module:

• The risk for rewriting a module which is a smaller part of a larger system is obviously lower than to rewrite the whole system at once. This sounds trivial, but it may be indeed the crucial factor of the decision, especially because the risk of a rewrite failure does usually increase overproportional with the number of code lines involved.

• The module must be isolated enough that it actually can be exchanged in isolation, without affecting the other modules. If that's not the case, one may have to plan a refactoring of the surroundings first to bring the module into that state.

• An architectural change of the module structure itself isn't easily possible this way, so if that's a goal, one needs a different strategy.

From my own experience, some years ago I was working on a product where we had to replace certain legacy technologies. We came up with a plan to do this module-wise for a lot of modules of the backend of the system, and we actually managed it to rewrite and replace one module after another, bringing it into production before we went to the next module. It took us some years, but it worked well, and finally we replaced the backend completely.

The front-end, however, was not modularized enough and way too much code to rewrite it all at once. We tried it, but after some months, it became apparent we could not manage it with our available resources. So we switched to a different strategy - to port the frontend (which was written in 16 bit C++) to the newer technologies (mainly C++/CLI), instead of rewriting it in C#. That allowed us to reuse most of the code without having to rewrite it.

So yes, rewriting single modules of a system - for example, for a technology switch, can make perfectly sense, especially when it can be used as a strategy to avoid a "big-bang" rewrite.