Rewriting Software from Scratch: Signs of a Need And Resulting Benefits
Published: 2021-01-05 20:39:56

Today is the era when we deal with a vast amount of technologies, frameworks, and any possible tools to create a code. There is still great temptation to stick in the stack that 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.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ialh5pxb8o4m0rfzafco.jpg)

## 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**.
___________________ 
*Upd. Some readers here considered as an offense the fact we're calling Perl obsolete. We didn't try to offend anyone by all means, of course. Maybe the word itself sounds too offensive for them, but let us dot the i's and cross the t's.*  

*The business isn't operating such concepts as an offense,  focusing on economical entities. From the point of revenues and spending, keeping Perl-based projects up and running in most cases is a bad idea. Finding the right people for maintaining a Perl-based project is certainly more challenging and expensive than for the one written on Python or any other more popular programming technology.* 

*What is more, no one from our opponents proposed starting the project for business from scratch using Perl. This fact looks like the main evidence that we were at least partially right in our suggestions.* 

*The guys in the comments were right about Perl's current usage scope which turned out to be wider than we originally evaluated.  It is still quite requested in some niches like the administration of UNIX-based systems. And it is appeared to be more young blood in the community than we expected. So, we want to say sorry to those people who were insulted by our opinion.*

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/xc356p5d098nhx5f7szq.jpg)

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.

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

## Some Helpful Advice

Do 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 **real users** during the design. But don’t let them tell you what’s to do.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/bowo4yb8pb1b4ti9pnz3.jpg)

## 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.