Rewriting Software from Scratch: Signs of a Need And Resulting Benefits

Today is the era when we deal with a vast amount of technologies, frameworks, and other possible tools to create a code. There is still great temptation to stick in the stack which has been popular years ago and “keep it working as it goes” is the best option. Sometimes it really is, but mostly not.

Well, we can provide a few firm arguments to describe why we suggest writing the project from scratch rather than keeping it alive and adding new blocks in the Jenga tower.

A Legacy Code Hazard

Before we go into the facts, let’s a bit talk about legacy code, why we preserve it, and how it might harm the business.

To cut a long story short, legacy code is the code we have, from the very first symbol to the next updates and versions. Often being modified many times before, such a code could be rather complicated in understanding and correcting.

As a result, the legacy-built project is becoming more and more expensive for the business to maintain. Eventually, it turns out to be cheaper to rewrite from scratch rather than to maintain further. Despite that, many businesses continue to keep the legacy up and running even when the difference is becoming multifold.

How To Catch if Your Software Must Be Rewritten from Scratch

So, how to understand you need to rewrite the code and refuse from legacy code entirely? There are some implicit signs that you should consider as a signal:

• Any of the programming language, framework, or platform used in your software, is currently considered obsolete. For the business, it means more and more spendings required for its maintenance.
• The software doesn’t handle the actual standards. It could be a lack of support for actual browsers, insufficient security level, etc.
• During the life of the software, a way better replacement was launched for one or more technological solutions used here.
• It is becoming obvious that the software will be unable to cover some future business needs. Of course, you can implement the required feature on your own using the custom code, but it can cost you a new Boeing.
• The deployment process cannot be automated due to the complexity of the existing architecture. Usually, it is caused that the single component cannot be properly isolated from the others. As a result, a single change causes a cascade of other ones.

From our side, we can add the list of technologies we assume is rare to be in use now:

Perl, Objective-C, Pascal/Delphi, Fortran, Cobol, Basic, Flash, PHP (versions 5.6 and below), AngularJS (aka Angular 1), Backbone.js, Knockout.js, Laravel (versions 5.0 and below), Symfony (versions 4.4 and below), as well as any custom-built CMS or framework.

These technologies should be better started from scratch as it is very difficult in modifying and adding a new technology stack above. It also required a longer ramp-up period from the new team to understand the code and make the first commit.

More Signs the Total Rebuild Is Needed

According to one more opinion, where there are a few more signs you need to rewrite the code, that you didn’t develop yourself:

• The software’s vendor announces end-of-life (or goes out of business).
• The software’s vendor hasn’t produced a new version for several years. (Or the open-source project you used goes dark, or gets forked.)
• The vendor has brought out a new product that does the same thing, and never mentions your product in marketing anymore.
• The vendor still supports your software, but support costs are rising steeply because it is costing them more and more effort to maintain it.

And we can agree with that and can say that taking these facts into account can work positively and make good progress for your business.

Benefits of Starting from Scratch

Let’s briefly remember the benefits that development from scratch brings to your project.

1. No more spendings beyond required. Your software will be designed in full accordance with the actual needs of the business.
2. Fully compatible infrastructure. Understanding the required scalability, you can set the proper infrastructure.
3. Easily add whatever you need in the future. Understanding the needs of the mature business, you can set the slots for future improvements.
4. Freedom from the legacy. A new code is free of previous issues.
5. Much more secure. Using up-to-date technologies makes breaches less likely to happen.

Some Helpful Advice

D o not forget that the step-by-step redesign of the existing system always costs more than the complete rewrite. At the same time, such radical change impacts both business processes and staff much higher.

So, the answer, whether it’s a time to rewrite or not, is often laying midway.

Some pieces of advice that help you succeed:

1. Building the system fully from scratch, do not try to use the legacy in any way.
2. Users’ migration is always painful. To make it less, first, divide the users into working groups, then migrate each group separately. The most troubled groups should migrate first.
3. The architectural design must be based on the business needs only.
4. The fewer technologies are used in your stack, the better.
5. Communicate with the real users during the design. But don’t let them tell you what’s to do.

Finally

From our experience, we have a few projects where we deal with code refactoring and code rewriting. In both cases, we’ve conducted careful research before suggesting the options to the client. So that really works, being in dialog with the client, hearing the pains, and working out the plan for how to improve the business and make it grow.

Please feel free to share your opinion in the comments!

The article was originally published at https://expanice.com/article/rewriting-software-from-scratch-signs-and-benefits