Table of Contents
Many business owners face the challenges of mounting technical debt in the process of software development. At some point, software application code becomes unmanageable and the development team has to take efficient actions.
The consequences of the long app operation must be either refactored or rewritten. And a legacy code can be very costly. Both of these options – rewrite and refractor – have their advantages and disadvantages for stakeholders and developers.
In this article, we will discuss how to deal with unmanageable code or legacy code, depending on the particular project, type of app, team’s capabilities, and main goals for the app taking into account pitfalls and risks.
Code rewrite
Writing new code is a more complex way to deal with unmanageable code. A programmer has to rewrite the code from scratch preserving the functionality. It requires splitting the software development team into two groups – one for maintaining the old code and the other for creating the new one.
Advantages of the new code
- Expands the target user’s audience, opens access to new market segments, and allows moving client-faced apps to a desktop platform or making it web-based.
- A new development team can instantly implement the code they are comfortable with
- Rewriting banishes legacy code and allows to adapt of new technologies and approaches easier.
Disadvantages of the new code written
- Rewriting is more time consuming and requires more resources since two teams will be working – one to maintain the code and the other to write the new one
- The team which maintains the old code in the process of live code cleaning can potentially introduce new bugs and defects, which need to be fixed
Refactoring existing code
Software refactoring presupposes the improvement of the internal code structure without influencing its external behavior. Sometimes, software developers split the part of the code, each with a single responsibility. Developers who regularly refactor code, make it more understandable and will be easier to update. Refactoring can be also referred as a code cleanup.
Pros of code refactoring
- Refactoring code is allowed the option for any developer, who starts working on a code
- Unlike rewriting, refactoring allows moving forward with the deployment processes
- No need to maintain two separate code bases
- It allows cutting the project expenses since you can clean up only that part of the code, which you are working on
Cons of code refactoring
- You cannot fix available architecture problems
- New functionality cannot be added since architecture and code are unchanged
- Refactoring demands software developer skills and discipline to cope even with thousands of lines of code.
What experts say
According to the point of view of J.Hanselman and D. Shiffet, the “big rewrite from scratch, because this is a mess”, is a losing strategy.
Of course, there are cases, when an old system and faulty software requires to be rewritten since there is too much technical debt to deal with it. You can use automated testing, and tools, to define and start working on the most damaged parts of the code.
In case you have a part of a code, which is written in a defunct language, which is not used anymore, probably you will need rewriting to turn to something more up-to-date. If you have a line of business application written in a defunct language that no one knows anymore, you’ll probably need to bite the bullet and commission something modern.
In many cases, software engineers choose to rewrite code. The creator of Stack Overflow, commented, that the reason why more and more programmers choose to rewrite code is that “it is harder to read a code than to write it.” And that is the ultimate truth. However, the time and resources it will demand sometimes prove that refactoring was the better option.
When a new development team is onboarded on a project, they found the existing code too complicated, and insist on rewriting it. Nobody wants to deal with the legacy code and long and complicated onboarding process.
J. Yaunches : “What people are looking for when changing their business needs are adaptability and flexibility. Flexible tech provides flexibility and allows to exist with the market shifts and new trends.” Thus you need to define where are your standing now and where you want to be in the future. It will help you to define the right strategy.
The thinking process you may go through to take the rights decision from D.Martell, a founder of the US SaaS Academy:
Love your legacy code, if you have revenue, customers, and code – it will be a tough decision. If you do not have data security vulnerabilities and glaring data concerns – consider refactoring.
Is it possible to achieve the same result by refactoring as by rewriting?
To be objective, refactoring is considered a safer measure than code rewriting. Primarily, it is performed in short iterations, it is much simpler to plan, test and release the changes. Secondly, while starting from scratch, you risk stopping halfway through due to system malfunctioning or budgeting overreach. There are no such risks with code refactoring.
Reasons to consider rewriting:
- The app runs on outdated software
- It has outsize dependencies on dying software
- There are new features requests, which are incompatible with the existing architecture
- The old code is simply a mess and cannot be managed the way it exists
Reasons to consider refactoring:
- You need to decouple components and reduce the code complexity that arises
- You need to make code more extensible, speeding up feature development
- There is a necessity to improve the performance
- Acceptability to reuse the code in the new project
Consider the best way to deal with the code - business cases
Estimations
Budgeting is one of the key factors that will drive your decision. You need to know the velocity gain since it will allow you to calculate the cost of adding new features. For sure, you need to calculate the cost of the rewrite itself, taking into account code quality, scalability, security, and future-proofing.
Team
If you are committed to the team, rewriting sounds like an attractive option. However, the time and resources spent on rewriting together with the ever-complaining users turn this option into the less attractive one. You should be aware of the risks.
Money
If the product still allows you to make money, you have enough time. You can make reservations to keep the option of rewrite. The more you save up, the quicker you will be able to rewrite it if the need arises. Moreover, doing a rewrite including the new features is less expensive than doing the new features on the existing stack.
Features
Estimate the features you need on the current tech stack. If you can turn the business profitable without rewriting – it is great, you may consider doing it first. However, considering, that rewriting can take longer than planned, however, it may be less expensive than introducing new features on the existing stack.
Risks
There is no risk-free option. You should consider your situation, analyze and assess current risks, define a clear path that will lead you where you want to come, and after considering all the possible paths, choose the optimal one.
Altamira will help you at the crossroads of your project
Business owners may feel lost at the point when they need to scale their team and the best new developer explains that the old system code is unmanageable and new features can only be added after the code rewrite. It is impossible to predict the outcome of the decision.
At the crossroads of your most essential decision, the Altamira team is ready to conduct the code review, access the situation, suggest the best option and assist you through the whole process.
Our team will take into account all the developers’ and stakeholders’ considerations, providing expert-level engineering expertise. With the help of our team augmentation services, you will minimize the possibility of technical debt, our team will ensure high-quality, clean, and maintainable code.
- Our engineering team will examine the existing code
- Decide on a desired, efficient, and flexible architecture
- Gather all the necessary metrics
- Discuss and plan all the necessary changes
We approach each of our customers and one’s case individually. We understand that the right decision ultimately depends on budgeting, time, resources, productivity, and many more factors. Our experts will minimize risks and save your costs. Technology moves on and today’s productive framework can turn into legacy software in the blink of an eye.
To sum up
At some point, all developers must decide whether to refactor code or rewrite it. Base this choice on factors such as architectural soundness, time, money, and goals.
The developer is required to either refactor or write application code when it is impacted by a defect in its code. With refactors, developers make micro changes that improve the code. The rewrite throws out almost everything and the coding begins again. Neither of the two options offers any advantages.
The code is rewritten without requiring significant changes but is not necessary for new development languages or applications to be built in. Code editing allows the fundamental modification of code but can cause confusion or even failure of the product’s functionality.
When it comes to such a decision, the refactor vs rewrite dilemma is always disputable. There exist no one clear path, since there are no identical projects and conditions. Even if you are one step from making your choice, stay cool, wait a moment and choose the approach, which your project will benefit from. Choose the most value for the lowest price, in terms of money, time and effort.
