A new framework won't solve the problem

One of the recurring tasks as a software developer is to fix bugs on tools that have been designed for an earlier time. You may get a project that was written in PHP 4, or a JavaScript tool that still tries to sniff for Netscape. It is easy to see how outdated the tools are and try to upgrade them. Most often than not, the task turns into a complete redesign rather than a bug fix and it ends up costing much more time than originally planned.

I am guilty of doing this. Every time I see a PHP project written in spaghetti code, I roll up my sleeves in excitement and create a new project where I can rebuild every single feature in a more organized way. I usually starts with the parts that I am familiar with, the parts that are closely related to the bug. But as soon as I move past those sections, the speed of development drastically decrease.

When a project has clocked-in years of prior development, there will be a lot of little caveats. You might see some things that look at the very least, very stupid, and be tempted to delete them. But the previous developers had put it there for a reason. A lot of things won't make sense. In your quest to reorganize data you might end up creating more problems than you are solving.

The problem of reorganizing

It takes more time than it is worth it.

A step that should happen before reorganizing the code should be understanding what the current code is doing. You might have the best of intentions or the most prominent framework, but if you don't have a mastery of what the current code is doing, you are not organizing. You are disorganizing an organized chaos.

A long running project had almost certainly received thousands of bug fixes over the years. Coming up with a new framework will more than likely reintroduce these bugs. Let's face it, none of us ever write efficient documentations that can be helpful to recreate the entire project. Even if we do, no one reads the documentation in that fashion.

Reorganizing means converting. Converting means you have to understand each part entirely before you can translate it into your new paradigm. It means sometimes you have to go beyond just reading code. You have to talk to the people who built the tool in the first place (if they are still around). You will spend time testing making sure the result match the previous version to a T. And this will require much more time than originally planned.

Examples of breakage

I recently had to fix bugs on a five thousands lines bash script. If you are not familiar with Bash, let me just tell you that every variables are globals. One variable was defined in the beginning of the file and then half way through a new variable was created with a very similar name, meaning the exact same thing, and eventually a developer confused the two and interchanged them.

This can happen in any programming environment, but when everything is a global and you have absolutely no scope whatsoever, converting it to a better programming environment comes to mind. I decided to convert it to PHP, since the project had some PHP already.

It was easy to fix that bug and convert that section to PHP. That was roughly 100 lines of code. But... how about the 4900 lines left?

Yeah exactly. As good as my intentions were, converting all this code would take a considerable amount of time. And I only came to this conclusion after I tried to convert some functions and realized that they depended on other functions, and those also depended on other functions and a few globals, and yari yari yara.

Now here is the thing. If I fixed the variable name in Bash, I'd be done with it and probably be working on something else. Instead I have wasted time trying to rebuild something that was only slightly broken.

Should I never reorganize old code?

No, you can reorganize old code or even convert them to new frameworks or programming languages. But this has to be the main task. Meaning you can't convert an entire project because there is a bug. If there is a bug, your task is to fix the bug period.

When the overall code has problems, like performance, or hard for multiple developers to work on, or you are going through a migration, then yes. You can create a new task/branch with the intention of upgrading the project. It can work in parallel with bug fixes and small feature design. It may slow down development, but at least it won't stop it entirely.

More often than not, when I try to redesign everything to fix a bug, I end up reverting the code and simply fixing the bug. Despite my enthusiasm in starting fresh, I try to remind myself that rebuilding an entire project is a long term project in itself, not something I can do every time I feel excitement.

I hope this helps you avoid unnecessary frustration.

---