Get your recipe books ready to take notes, we will be learning the proper roasting of the legacy software.
What is legacy software?
Let’s start with the definition of legacy software. Actually, there are many different definitions, but I like this one: legacy software is any software that you are not writing right now. I like this definition because it removes the stigma. If a PR was submitted yesterday and it was merged into production, congratulations, it is now legacy code.
Sometimes, engineers are truly afraid to change legacy code. This isn’t unreasonable. The fear can stem from insufficient test coverage, lack of documentation, outdated technology, or a complicated dependency relationship between the modules. Changing it poses a high risk, because the changes can introduce unforeseen regression in all code that depends on it.
Often, this code is maintained by a handful of individuals who “know how it works,” and any attempts to introduce new engineers into this circle are accompanied by frustration and high business risks. The company can be caught in a very dangerous trap if a third-party vendor maintains the legacy code, and no one in-house knows how to manage it and/or has no access to it. A business must have a clear, efficient way to manage, change, and understand every piece of their software and technologies.
Symptoms
- Insufficient test coverage (or no tests at all)
- No project documentation, only a small subset of engineers know how to maintain the code
- The technology used is outdated
Business Risks
- Adding new features or changing existing features becomes slower
- Domain knowledge is concentrated into a small group of engineers, increasing the risk factor
Perspective
Legacy software is everywhere. However, some people automatically view legacy software negatively, picturing a large, outdated system or a solution that's been around for ten plus years. We don't subscribe to that viewpoint, because the fact is, software changes so fast that the tools and even the approach used to construct software can be made obsolete in a matter of months. In which case, it's essential to look at software as something that is evolving, something that needs to be taken care of and kept healthy constantly.
However, there are a couple of roadblocks that commonly pop up when you are trying to solve a legacy software issue. One, it's really hard to ask for help in the software development industry. In some ways, that's just a business problem. It's hard to go to a CTO or key stakeholders and advocate for money to hire new engineers solely for rehabilitating a system that may be unhealthy.
There's a stigma there, and you have to explain some very technical issues to non-technical people. It's really easy for that conversation to get turned around into, "Why isn't it healthy? It was your job to keep this thing up and running and successful forever, so why would we need to bring in anybody else?"
This is unfortunate, because every system needs help at some point.
No software program has ever been released without bugs. Sometimes those bugs get quick and dirty fixes, but there needs to be more focus on going back in and rebuilding and finding a true fix. New business features are the biggest driver of legacy code maintenance issues, because it’s often easier to bolt on a quick solution, rather than going back and planning and viewing the entire architecture and looking for the best way to add a new feature.
The question is, how do you know when the system needs help? Running proper diligence is key. Sometimes that starts with a simple code audit, if it's a small project. For larger projects, it may require the engineer to sit down and work with the rest of the team and try to do something simple, like build a new feature or resolve a bug.
In order to do proper due diligence, you need to understand the development process. Because processes involve people, and human error will always lead to technical problems. Diving into the process is a reasonable step to take to trace back the causes of legacy software issues. Watch and learn how engineers do their jobs. It’s best to start with easy questions about the processes. For example, "How do you gather requirements? Who does acceptance? Where's the staging environment? What's your cadence? How often do you release?”
Questions like that are process-oriented at the surface level, but underneath they have a lot of technical underpinnings. If a company releases to production once a month, ask why. If you ask, "What does the release process involve? What does it take to release?” The answer really should be, "We run this command.” There should be a single button or a single command to deploy.
There will always be improvements you can make to a codebase. However, that doesn't mean that those changes are needed right now. A big part is understanding where the system is now and how safe it will be to push a new feature into production. This involves asking more questions, such as, “Are there any automated tests? If so, where are they? Is there a CI/CD pipeline? Where is it? How do we run it? How do we evaluate the feedback? Is there a staging environment that exactly mirrors production?”
The good news is that, if your legacy software needs improvements, it’s possible to make some really positive strides on a shoestring budget.
For example, if the engineering team SSH-es onto the server, it’s better to consider getting off of that and putting CI/CD in place, to get to the point of confident releases. Or at least get to a point where the existing team can test something in a staging environment before it goes out into the world.
So, what else can you do in advance to try to avoid some of the legacy software pitfalls? There are plenty of books on keeping the software clean and adhering to software and architectural patterns. Some of these books have been around for decades; others are still being written. But we think the best thing you can do is to continue learning yourself. They say the mark of a good programmer is that they can look back on the software they wrote six months ago and say, "Oh my God, I can't believe how I wrote that.” Constant learning results in constant improvements.
From a software standpoint, there needs to be consistent attention and care given to the software. We can recommend using tools like Code Climate, keeping an eye on the software, checking on dependencies, and monitoring software complexity. But, the biggest thing you have to do is continually ensure that adequate time and effort are put into the system to make it healthy and keep it healthy.
Full whitepaper
The ideas outlined in this article are part of the more comprehensive whitepaper designed to guide CXOs and tech leaders in reducing tech debt using agile software development, avoiding the pitfalls of legacy modernization projects, and effectively managing software developers.
If you want to get the full white paper, visit a page to learn more: https://evrone.com/fast-development
The Overview: What’s inside?
- The main blockers of Fast Development
- Tips to avoid legacy software pitfalls
- Business risks of using outdated technology and tips for choosing the right solutions
- Safety risks associated with externalizing functionality
- The importance of continuously evolving project architecture
- Speeding up with code quality tools
- How to reduce tech debt
- Predicting your ROI
Disclaimer: I am a business executive at Evrone, a software design and development company. If you have feedback or ideas, drop me a line at [email protected]. Feel free to connect with me on LinkedIn, as well.