Dealing with legacy code is inevitable and can be a real challenge. The right attitude and the way you approach the legacy system will affect the success of a project. So what difficulties might you face when working with legacy code?
Legacy projects usually come with having to decide whether to maintain the code or make significant changes. While maintaining legacy code costs time, money, and even people, convincing a client that it’s time to refactor and keeping developers motivated can also be challenging.
What is legacy code?
For me, it’s old and messy code written without frameworks and using outdated technology. It’s unstructured, full of ad-hoc logic, and without documentation, so everything typical for the so-called spaghetti code.
Grzegorz, Backend Developer
Even though it’s code written years back with outdated technology in mind, it still has business value because it works. So developers shouldn’t judge a piece of code too quickly.
What are the most common problems when working with legacy systems?
Developers hate dealing with legacy code
The truth is that developers simply don’t want to deal with somebody’s code. They want to develop a project from scratch, using new technologies. This makes them have full control over the code, so they are more motivated when coding.
Legacy code usually equals large systems that have been developed for years, so such projects may demotivate your development team. The goal is to instill the right attitude to deal with legacy code to avoid high staff turnover.
When a software house perceives refactoring as the cure for technological debt, team members feel that they are doing things that matter. And one of the key responsibilities of every project manager is to boost developers’ morale, which helps to reduce the time spent on analyzing and understanding the current code.
Business pressure for developing new functionalities
The longer refactoring is delayed, the bigger the debt because of more code added. Plus, business pressures influences a product, as more functionalities mean more money to a client. And this customer-driven business pressure simply leads to technical debt.
It’s the project manager’s responsibility to quickly spot such constraints and make clients aware that a shortsighted view can compromise product quality and introduce technical debt. S/he should know that some time should be allocated to refactoring to improve the project.
Every new feature can harm existing application
Nonsignificant functionality may cause a collapse of the entire app or every new feature can add debt. It’s especially common for monolith applications where one element depends on the other, so a single change may affect other parts. Hence such applications require extra time for testing.
No up-to-date documentation or lack of documentation
Reviewing documentation helps to understand the code. But when a project comes with little, insufficient, or no documentation, the implementation takes much longer than expected. The same goes for outdated documentation that becomes useless for developers. It can take weeks to understand a poorly written application, so it generates extra costs.
Rewriting isn’t always an option
If you think it’s faster to rewrite the code from scratch, make sure it will pay off. Even though it’s tempting, in most cases it takes a significant amount of time and resources, so it’s usually a business decision, not a technical one. Not to mention introducing new bugs that didn’t occur in the current version.
There are, however, some reasons why you can consider rewriting the code. You can then, for instance, break a monolith into microservices, which is an emerging trend in software development.
The most important thing is to rewrite the code only when it’s necessary, and it’s usually better to refactor it. Refactoring helps to eliminate problems before they become costly, but it has to be done with business needs in mind.
Although understanding legacy code and making it more functional can be a real pain for developers, it can turn into joy with the right attitude.