Please don’t rewrite your system from scratch

It seems there have been a lot of discussions online recently around rewriting software.

I think it’s a great discussion to have, as on many many different projects, I have seen developers clamouring to rewrite the software, to update to modern tooling, to fix large sets of issues as they see them in the codebase.

For the most part, prototypes of a newer, modern codebase can be created in a matter of hours. It can be very easy to assume that with modern tooling, and a prototype, rewriting a system is an easy job.

For the most part it is not.

I have personally seen a number of rewrite projects, and for the most part these rewrites are far from easy. With a rewrite, all of the necessary complexity of the system has to be addressed all at once.

Most of these recent discussions would also advocate incremental improvement over a rewrite, refactoring towards a target architecture. By all means, create a prototype of where you think the system should be. Then, armed with that information, work out how you can get there gradually.

The first part of this has to be understanding your existing technical debt.

Work out what is costing the business the most right now, and look at refactoring that towards your vision of where you should be. It might take a while to get there, and you will have to take many steps along that path, but you will be doing so in a much more controlled less risky way, providing more benefit up front.

In my new course, ‘Dealing With Technical Debt’, I go into this in more detail, and look at ways we can compare instances of technical debt in order to prioritise them. Once prioritised, we can look at improving the system in a deliberate way, tackling items that will bring the most benefit first.

Sometimes you do indeed NEED a rewrite. And sometimes you can even pull it off, but often it’s better for the business and all developers involved to put in place a strategy for dealing with your technical debt.

When done right, this can actually allow developers to use the languages, techniques and tools needed to develop as they should, but do so in a more gradual way, allowing results to be seen early.

What do you think about rewrite vs incremental improvement? Have you seen any cases where a rewrite was successful? How do you manage your technical debt?

Leave a Reply