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.
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.
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:
- Building the system fully from scratch, do not try to use the legacy in any way.
- 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.
- The architectural design must be based on the business needs only.
- The fewer technologies are used in your stack, the better.
- Communicate with 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.
Top comments (11)
The assumption you made about Perl being obsolete is wrong. It is perfectly suitable for various tasks from system administration to web development. See the Modern Perl trend and frameworks like Mojolicious.
Hello Sébastien! I see you're a Perl enthusiast and even a member of the Perl Weekly editorial team. And all your geese are swans, of course. Indeed, I haven't an intention to derogate from the value of the tech you're best with. But let's make sense of it. When we speak about Perl, we mean Perl 5, which initial release was in 1994. Perl 6 is in the permanent "Under construction" stage since 2000, but in 2019 the name was changed to Raku, so, actually, it is not Perl. And this fact reminds something. What's to the fifth version, it's by no means mainstream. Currently, Perl is the 17th most popular based on TIOBI Index with ~1%. Of course, there is still much working software based on Perl. And such enthusiasts like you are in high demand thanks to employee scarcity.
dev-to-uploads.s3.amazonaws.com/i/...
But please tell me how many juniors in your community? I bet there is no sign of people with less than 10 years of Perl experience in your community, not by a long shot, right? At Glassdoor, I've found just a couple of Perl-focused positions among much more where Perl was just mentioned. Almost all of them include Perl as a part of requirements kinda "Experience with at least one scripting language (Python, PHP, Perl,…)", so, Perl is just an extra here. No offense, but nowadays Perl-based software is highly likely obsolete, and most often a complete rewrite of it using something more popular and up to time is the best idea.
I would disagree with this. One of the things the Perl team does, is prevent obsolescence. There are still updates to Perl 5, it's still moving forwards, it's still keeping old software supported. I think it's different when a team decides that a language will no longer receive updates etc (eg Python 2, what happens if there's a security flaw found). We still code new things in it. We know other large sites that use Perl extensively.
Sure, there are much more flavours of the month out there, but like some other languages, Perl has stood the test of time. There are no surprises with it, no sudden breakages. I do agree about less specific Perl programmers out there, and sure, not many new teams would choose Perl as a language to start a project with (unless a good familiarity with Perl already).
To clarify: I am not a member of the Perl Weekly editorial team.
The fact the language is unpopular doesn't mean it is not suitable for most of the imaginable tasks. And it's oldness make it very stable. Also the unpopular aspect push companies to hide their own use of this language (they wouldn't like to scare people). For example, most of Unix like systems requires Perl for proper functioning.
There are all kind of trendy technologies that get much more appeal, but this one is still there after 25+ years.
I think judging anything by popularity is biased and in this way, TIOBE is rather meaningless.
In the Perl community I remember of a very good storie about "rewriting from scratch" an application that was functionning. Two years later, and an explosing budget, the rewriting project is cancelled because the initial Perl app was faster. Yes, faster! Perl 😂
I'm sorry but you just lost your bet. I have no more than four years of Perl experience and I'm a member of this community.
Perl 5 release date does not matter, because for many years it was locked to major version number 5 due to Perl 6 experiment. With all the new features and all the excellent community modules, it is a completely different language than even perl 5.8, not to mention 5.0.
BTW I have only < 4 years of professional Perl experience.
Hey Sebastien! We finally decided to make an update to clarify our position and make it unoffending. Thank you for the discussion, we hope the current explanation finally made the position expressed in the article neutral in your opinion. Cheers!
I actually never found the post "offensive": it just looked plain wrong and sad for your company to publish such facts that show a relative ignorance of the subject.
Now you updated the post, I actually feel really offended.
« Maybe the word itself sounds too offensive for them. »
What is that even supposed to mean?
We mean the question is not in the Perl or any other given technology but in the business. So, 'obsolete' here could only mean 'most often unprofitable or less profitable for the business to be used here compared with other potentially applicable technologies'. I hope now it sounds better?
Your points about software rewrite are useful, but you could remove your very subjective list of obsolete languages and still have a good essay. You may not see Perl, Fortran or Cobol in your part of the world, but I assure you they are holding together large parts of the software universe, and they have active communities that are still refining the language and tools. When I think of Perl, I don’t think of Perl 5 from 1994, I think of Perl 5.32 that was released in 2020 (and the dev point release 5.33 that was released last week). You correctly note some true cases of obsolescence that need replacement, but these languages are not among them.
Hey guys! We finally decided to make an update to clarify our position and make it unoffending. Thank you for the discussion, we hope the current explanation finally made the position expressed in the article neutral in your opinion. Cheers!