5 Keys to Successfully Managing Legacy Code

I feel like there is always a big focus on developing new features, launching the next product or the next big thing, but once those things are successful there is an extraordinary challenge that teams face in managing their legacy code. Even the latest and greatest software at some point becomes legacy and it isn’t always possible to just drop the product line and move on to something else (unless of course you are Google). Once there is a user base, the code may need to be maintained for a decade or more. In my travels and online conversations, I encounter a lot of teams who struggle to maintain their code. I’ve found that they often are solely focused on the code, but it turns out that there are actually five keys to successfully managing legacy software in a timely and cost-effective manner. In this post, we will briefly explore these five keys.

Key #1 – People Management

The first key to successfully managing legacy code is to manage the people on the team. Now I’m not necessarily talking about day to day management of developers, but I have seen a lot of very successful developers whose skillset have become frozen in time. They start out with the latest and greatest skills and processes, but from constant work, pressures to deliver the product and updates to it, they fall out of sync with the rest of the industry and before anyone realizes it, they are frozen relics using outdated processes, tools and techniques. These developers may still be successful, but they may not be as efficient as they could be and depending on the processes and skills it may make it very hard to collaborate on the code or make changes to it within a predictable timeframe.

Now before anyone gets embarrassed thinking that I may be describing them, this is something that can happen to any development team. I’ve been working in embedded systems now professionally for over 15 years and I’ve found myself occasionally starting to become a frozen relic if I allow myself to get too heads down on project work. Several times throughout my career I’ve scheduled considerable time to learn, test and implement new processes, techniques, technologies and so forth. No team is immune and therefore should have a plan in place to not just help their team stay up on the latest industry trends and techniques, but to also have the time to test and implement those skills and make improvements. New skills are critical to ensuring that developers can successfully leverage the latest skills and techniques when managing and developing software.

Key #2 – Process Management

I’ve found throughout my career so far that processes are the necessary evil that can generate consistent, predictable results. Industry processes change over time. Some processes that gather a large following may be found to not produce the desired result and might be abandoned. Others may prove to be a foundational cornerstone that no team should go without. The teams that I have worked with that have been the most successful are teams that carefully manage the development and business processes.

Over time, processes tend to accumulate to a point that they can choke out innovation and cause more headaches than they fix. This is why it’s important that teams remain flexible with their process management by performing annual spring cleaning on their processes. If certain processes are tying developers’ hands too much, remove them. If developers have too much freedom and are tripping over themselves, find an effective process that can produce reliable and repeatable results. Carefully balancing the processes that a team uses and making sure that they are updated over time can help to ensure that legacy software is updated and maintained in such a way that it is evolving with the times, which can minimize large modernization efforts.

Key #3 – Technology Management

Managing the technology that a product is based on can have a dramatic effect on how easy it is to manage legacy code. I’ve found that sometimes once the hardware is designed for a product, developers become accustomed to working with that single microcontroller, or that toolchain, or that framework. Technology evolves at a rapid rate and just because we used a particular development environment five years ago when we first developed the product doesn’t mean that is best or most effective environment for us to be working in. It may be the most comfortable for the moment, but there could be others that allow us to work faster and more efficiently. Just in the past three years I’ve seen huge leaps in compiler efficiency, code tracing technology, memory management and even security technologies.

Teams should be carefully reviewing what technologies they are using to maintain their software and evaluating what the latest and greatest technologies are. A team may decide to continue on the path they are on, but just being aware of what is there and planning for it to be implemented can help developers to plan for those changes and technologies. Then when the time comes, it’s not a major overhaul but just a seamless transition that was expected and garners new value to the team.

Key #4 – Tools Management

The tools that we use to develop and manage our software is so crucial that it’s often hard for me to come up with the right words to describe it. Imagine for instance that there are two home builders who are building identical homes. Each needs to frame the house but they decide to use different tools. Builder one decides to use hammer and nails because it’s what he’s most familiar with, it’s the way he has always done it and he doesn’t have time to learn any other way of doing it. Builder two, who is also familiar with using a hammer and nails, decides to purchase a nail gun. If they both start at the same time, who do you think will have their home frame first? Undoubtedly it would be the builder with the nail gun, even if he had to spend a little time at the start to learn how to use it.

Legacy code can be maintained and updated successfully if the right tools are used. These tools do change over time as there are always innovative companies and open source developers who are providing solutions to all sorts of problems. This is why there also has to be a process in place to learn about new tools, how they work and to outfit developers with them. Proper tool management can make things so much easier. For example, I’ve come across legacy code bases there were hundreds of thousands of lines of code. No documentation, monolithic, a nightmare if I were to try to understand the architecture and pieces only by doing a code review. Instead, I use a tool like Understand or Lattix or some other tool that helps me to quickly visualize the code, understand the architecture and then I can start asking the right questions (and far faster than if I did it manually). The right tool for the right job.  

Key #5 – Code Management

Finally, we come to the actual code management. The code itself, and even the software architecture should evolve over time. We often look at the code and the software architecture as fixed, but they do not necessarily need to be. For example, I often come across monolithic, tightly coupled code. The application code directly makes calls to the hardware which would make changing processors or hardware a major rewrite of the software. As I encounter code like this, I’ll often draw up how the current architecture looks and then draw up how I would like it to look. This usually involves identifying architectural boundaries and then within the code, with each release, making minor improvements and evolving the code towards the preferred architecture. I’ve found that this approach is very effective at evolving a legacy code base architecturally and that it minimizes major rewrites and headaches but still brings the code up to a modern standard. (Obviously with quite a few other things going on but I hope you get the picture).


Legacy code can be challenging to maintain. The trick to successfully and efficiently maintaining that code though is to understand that there is more to it than simply managing the code! We’ve examined the five keys to successfully managing legacy code:

  • People
  • Processes
  • Technologies
  • Tools
  • Code

All five areas to be managed successfully in order to make legacy code management not only successful but cost effective and efficient.

Share >

4 thoughts on “5 Keys to Successfully Managing Legacy Code

  1. I couldn’t agree more to most of the article, but it misses what I see as the really difficult point, how to sell this to management.
    Especially in embedded SW we often sit in companies that on mangement level is educated in managing a factory producing some kind of hardware. To those managers SW is still some level of invisible magic.
    I mean I as a SW developer can easily see the problems and compare a messy code with thousands of quick fixes to a messy factory floor where the main machinery is held together with tape, strips and Chewinggum, it can work but definitely not efficient.
    Let’s take Key #5, maybe I can convince management to allow the time to “draw up how the current architecture looks and then draw up how I would like it to look.” and maybe spend some time fixing a smal part, and we all agree that we need to “with each release, making minor improvements”. But because management is still not able to see the improvements inside this invisible magic thing (software). They loose focus extremely fast, and keep promoting developers who delivers quick fixes (tape and Chewinggum solutions), because when only looking at the output, not able to see the mess they left behind in the code (it is invisible), they look more productive.

    I am sure I am not alone in this picture, and this often is the reason for code that you describe in key #5. So yes I agree in most of the article, but I am having a hard time selling it to a management brought up in factory of goods.

    • Thanks for the comment! You are right in that it can be a challenge to sell to management. I may write up a separate article on this at a later time. What I have found works is that you have to provide the ROI and value in terms of the business for management to buy in. For example, making these improvement will cost us three extra weeks now, but it will improve flexibility and configurable that will save us eight weeks each year for the next 3 years. It can still be difficult, but they need just need to understand the effect it will have on the business.

      I hope that helps.

  2. You didn’t mention a suite of tests, which in my opinion is essential in giving you confidence that refactoring hasn’t broken anything.

    • Yes that is not mentioned here but test suites certainly have their place in this. Perhaps a topic for another time.

      Thanks for the comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.