When to rewrite code and how to know the time is right?
Sometimes, and in the case of aged, voluminous projects rather sooner than later, comes the time to decide on flipping the build upside down.
The dreaded CODE REWRITE.
Maybe you share with us the same memory from primary school. Once you got fed up with a poorly filled notebook, you decided to start all over again. The story ended each time the same – purchasing a new notebook, meticulous copying of previous topics onto new, unspoiled pages, often adding colorful annotations and other bells and whistles. Rewriting continued, but most often before you finished transferring all previous topics to the new, better notebook, something went wrong, and you either stayed stuck to the old one, full of scribbles and chaotic notes, or continued until the end of the term with two notebooks, none of them doing its job properly.
So that’s for our long-hidden memories of rewriting things. Years have passed, and here we are, talking about rewriting way more serious things than your 4th-grade biology notebooks.
We’ll start from here with something you might already know from our works, the process.
So, how to know it’s the right time for rewriting your build?
The above quote should apply to the considered technology rewriting. When done at the wrong time, it can have catastrophic consequences.
Too soon
Starting the rebuilding process too early can result in generating unnecessary costs. Proper business analysis should prevent us from taking such vital measures in case something may change in the distant future, while there’s no clear indication it’ll happen for sure.
Too late
As a software development company, we’ve come across examples of companies that haven’t decided to rebuild their structure when it still worked well. What they didn’t know was that their structures needed time to be rebuilt – and when the shift ended, it was too late to maintain operations. Should they make the decision earlier, the new infrastructure could be completed before the old build lost its capabilities to handle incoming traffic.
Before diving head-first into revolutions in your digital product, a proper health check of what lies underneath is necessary.
What to look for while doing the health check?
Assessment of infrastructure’s shelf-life should include the following matters:
Performance (scaling limitations due to architecture, outdated technology)
Your business is meant to earn and, most often, grow. What if the architecture that was fine at the beginning of your path has reached its limits? Moreover, since code rewrite requires time and the product is flourishing and gaining new users, will the structure withstand the expected workload e.g. a year from the point the need for changes is recognized?
Don’t let the inability to scale restrain the business from reaching new heights – make sure the technology you use is ready to handle greater traffic and workload. The same works for integration with new or upgraded external systems, which could potentially cause issues with the present structure.
Up-to-date manufacturer support for specific system components or user-side technologies (e.g. Adobe Flash Player)
You may be used to the technology of choice because it offered the best value at the time you incorporated it into created projects. Nothing lasts forever, unfortunately, and some solutions just fade to grey. This happens even to widely used and appraised tools, like the famous example of the popular Flash player ending up unsupported by the end of 2020.
Security requirements (security audits)
In this section, we wanted to use the analogy to actual weapons, but we feel that in March 2022, said comparisons aren’t fit for the business content. Back to the point – the security of your architecture is one of the most important matters, and as such, requires solutions good not just for now. Companies often face app safety challenges caused by security gaps in components used in the current structure which aren’t developed further. Instead of sweeping threats under the rug, the sooner the issues are addressed, the better for the build.
Choose wisely among reliable options with both, a good history and a good outlook for the future, to ensure the best protection against possible threats.
The ability (or necessity!) to move to the cloud
The cloud is a powerful ally in building robust software products and as such, helps with scaling according to the needs. Regrettably, not every business can or wants to move their build to virtual machines. In the case of e.g. a merger with another entity, assessment of whether the technology allows transition to virtual servers is necessary. Some companies want to move to the cloud due to economies of scale and workload (not wanting to maintain infrastructure left unused outside of peak times), but what separates the need from actual transition is the process of adjusting the architecture. Identifying challenges regarding the move and approaching them properly calls for in-depth analysis.
Strategic and corporate decisions
Business decisions affect companies on multiple levels and strategic shifts (mergers, acquisitions, partnerships requiring particular technology used by other parties, etc.) have side effects. As a result, rewriting the whole structure or some parts of it may be necessary to achieve compliance among used software to continue with delivering assumed goals.
Availability of experts in a given technology
In some cases, the search for the last remaining developers in languages your architecture consists of may not be worth the struggle. Let the 3 reminding Haskell developers carry on with their peaceful lives and consider rebuilding the system with technology that’s backed with an extensive, blooming community.
What else needs to be taken into account when considering rewriting code?
Time and costs
How long will it take and how much money do you need to secure for rewriting your architecture? In short – it depends. Whether the whole system will be rewritten or just chosen parts, the process can vary in length, complexity, and, what follows, costs. Code rewriting should be done in a set, finite time and estimations should take into account possible scenarios.
The challenges in estimating code rewriting boil down to the emergence of new ideas. Who wouldn’t want to include an array of new features, since the old package is already under construction?
Planning
So, you have a team that rewrites parts of the architecture for the better. But is there anyone still maintaining the old parts? You have a working product, used by thousands of people. The worst that could happen is affecting the way the product behaves, causing user outflow. Maintaining the working parts while others are rewritten can be costly, but losing clients is more expensive. Should the enterprise freeze their product and leave an “UNDER CONSTRUCTION” banner greeting users? This could – and often will – result in customer outflow. Most probably rewriting parts of the structure while others work unaffected will be the most beneficial strategy.
Data
A working product contains gathered data, which most probably needs to be transferred to the new structure. The migration may be a challenge in itself, as old data may need adjustments to be still useful in new conditions. Complicated migrations resulting from new architecture sometimes make companies wish they could abandon old data sets and start over again on the new structure (which is possible in some cases but can’t be considered a rule).
Old, but new
What will the architecture be after the rebuild is complete? Does it change only on the backend side (integrations, security, etc.) or will the functionalities differ, which also could discourage users? Take time to decide whether new additions are necessary to avoid overdoing.
One of our clients needed rewriting their old and complicated software to work properly in web browsers. We started with creating a new frontend, preparing the API to match the existing build. As a result, the client gains a working browser version, and we can focus on replacing backend elements, without disrupting the product’s functioning.
Communication
Sure, some inconveniences may occur and affect the users. Prepare ahead for such possibilities, ensuring the most transparent communication, reaching the clients before application downtimes will.
And one thing to avoid: hype
New technologies and other shiny bells and whistles need to stabilize and consolidate a little before you’ll trust them with your life’s work. We highly recommend focusing on in-depth analysis and business insights, instead of diving head-first into hype-driven processes.
The world changes. And so does technology
In a world where we’re all used to certain technologies surrounding us all the time, like the omnipresent JavaScript, Python, C#, we may forget – or not even be aware of – the great old ones, nearly ancient languages who were there when it was written. Being an archeologist seemed great when we were kids but dealing with old-timey programming languages poses problems. Usually having to unearth something nearly forgotten is a challenge to the company. Like COBOL, known since 1959, still used by some developers, who for some reason won’t be replaced by their successors.
If not rewriting then what?
As we already said before, rewriting the architecture is not just about the technology. The business models and needs vary, and there’s no one-size-fits-all solution. Turning the build upside down, however often necessary, may not be the right step for the company at any given time.
Maintaining the existing structure can be facilitated by refactoring, restructuring the code to handle the technical debt building up in the meantime. In some cases, refactoring your code can be sufficient to achieve desired results, and continue with successful operations. Tread carefully, as no solution is once and forever – instead, keep a watchful eye on your software, the way it behaves, and how the drivers change to be ready to act in time.
Is the time now?
If you have a growing feeling your architecture might require rewriting, but don’t know how to approach the change, book your 1-hour free consultation.
Approaching code rewrite requires a strategy, ensuring the process will affect your operations as little as possible. Our analysts and architects are here to help you assess the challenges and opportunities, making every effort to execute the process in the most beneficial way for you and your business.
