Dealing with legacy systems strategies for success

In general, it’s safe to say that most, if not all developers don’t like dealing with legacy systems. In fact, typically when faced with legacy systems, you will experience some resistance or even outright push back from your team. It’s key to ensure that your team understands though the system may be old, it still adds value so moving things from the current legacy system into a newer one is necessary.

Understand the big picture

Therein lies my first point of understanding the bigger picture. It’s often not just about this one legacy system, rather a network of interconnected systems that play a larger role which the developers can often fail to understand or see for themselves. Understandable as they are focused on the monumental task that lies before them. Nonetheless, be sure to lift your teams’ gaze to see the horizon and the bigger picture. Incorporating an older system with a newer one for a client is often necessary and unavoidable.

Ultimately there is value in the work being done as it is integral to the client’s business operations. The team should understand what the system does, what it’s purpose is, what the components of the system are and so on. What are all the technologies incorporated into it? This naturally will take the team some time to dive in and get down to what all the parts are and their purposes; though in the end, they will see the big picture and clearly know the path forward.

Focus on key aspects

Focus on that which is key to move forward with, and don’t get lost in the details. As a team, you must decide whether you want to focus on fixing a bug or implementing a new feature; doing both is not always an option. Various project constraints will limit the team’s ability to deep dive into every area of the legacy code so, identifying key areas to focus on will help in your plan of attack.

Begin with your environment, ensuring the team can run the system on their machines. Then begin to identify areas that may cause issues with new features, and give them some attention to proactively head off any issues down the line. Don’t waste time with areas that have little to no impact on what is upcoming in the architecture roadmap and feature list. To begin with, let’s just focus on a specific aspect and move from there!

Get control

Control cannot be overstated; what I mean here is the ability to feel you have control in what you are doing with the code. Knowing that if you begin to mess with this section of code, it will affect that section over there which in turn impacts the behaviour of function or feature X and so forth. There’s nothing worse than coding and feeling lost, as though you have no control over what’s going on.

Legacy systems present a variety of challenges to work with, and being in control of the code and how it’s responding to changes is key to moving forward in a clean, organized manner. If your team is hesitant to implement a new feature, it’s likely they don’t have full control over the code or understand all the moving parts therein. There may be a few elements beyond the team’s understanding, but at the least they must have control so they are not bereft of hesitations.

Be open-minded

Legacy systems are not that terrible; they get a bit of a bad rap. Be sure your team at least acknowledges the previous work done, perhaps show a little appreciation, and keep their thoughts fixed on improvements rather than that which they don’t like or feel isn’t good. There is always a silver lining.

Naturally as software languages evolve and improve, your team will view code that is a mere 2~3 years old with a critical eye or even perhaps something akin to disdain. This of course, is counterproductive and behaviour unbecoming of a professional top development team. It’s important to remind them that at the time, that may have been considered clean, effective, efficient code and measuring it by today’s standards will always see it fall short. Let’s look to improve on what came before so that what comes after stands even taller!

Promsopeak Sean Nuon
Sean Promsopeak Nuon
Lead engineer
Sean is technology-driven and passionate about working with technology that helps people. Now he finds himself as an executive member of Slash, executing the technology operation side from an entrepreneurship point of view. He has over 9 years of working experience dealing with technical problems, project management and team mindset building. He splits time between Solution Architect & Lead developer for enterprise clients and as part of the management team, he helps build future-proof architecture, define quality standards, team culture, and hiring & training practices.
In this article

Explore more resources

Consider these 5 Factors Before You Choose Web and Mobile Apps Service
Articles
Consider these 5 factors before you choose web and mobile apps service
Before choosing a web and mobile apps service, consider these 5 essential factors to ensure you pick the right company for your business. This brief guide will help you navigate the selection process effectively.
8 minute read·
by Alex Lossing ·
November 14, 2023
Ethical Dilemmas in Product Management: Navigating Responsible AI
Articles
Ethical dilemmas in product management: navigating responsible AI
10 minute read·
June 19, 2024
Search
Skip to content