As a junior developer you learn and get quite intimate with many legacy systems. It's almost like a rite of passage, you finish school, interview, get a job and your first project is working on a legacy system the rest of the team hates. Or if you are new on a team you pick up a legacy tool or app that no one else wants to touch. Funny thing is, as you go through the ranks and become more senior you also tend to get more intimate with many legacy systems. Usually they fall into your lap during changes (management or leadership), acquisitions or if you produce results you are guaranteed to be saddled with technology no ones else wants to deal with.
In the midst of chaos, there is also opportunity.
- Sun Tzu
I can personally relate to this experience because I've been through it many times. In my first corporate position I was tasked with "playing firefighter" for months. This basically meant I focused on all the emergencies and urgent issues so that the agile team could focus on delivering their sprint objectives. I was the newest on the team, so what better way to learn about the business and its platforms than having to "put out fires" (i.e. deal with urgent issues). One of the many lovely experiences during this time was when I had a site that would go down every hour on the hour for 10 to 15 minutes. It was so common, business stakeholders wouldn't even make much noise about it because they had come to expect it. However, every time I received the alerts it would send me into a panic. I would rush to SSH into the machine to restart processes. I hated operating in this way. So I figured out a way to automatically restart those processes without having to manually restart start them each time. This reduced the down times to 1 or 2 minutes.
Now, I could have been satisfied with that; it was a huge improvement and the business was happy the impact was reduced. However, I kept seeing the alerts and knew I could fix the core problem. Actually, because the outages were so brief now it gave me the confidence and time I needed to focus on fixing the underlying cause, rather than spending the majority of my effort in "emergency mode". I spent days looking at the site and its code, and after some debugging and profiling discovered a few things that were causing the outages. It was fixed permanently and outages stopped happening.
Funny, about six months later, the site went down for some new reason, unrelated to the fixes I had made. I received the alerts, however, this time I also received a phone call. The main stakeholder was calling to inform me that the site was down and asked me if I was aware. Luckily, it was a short outage and I addressed it quickly. I called the stakeholder back and informed him of the issue and that the site was back up. We had a good relationship, so I said to him, "when I first started this job this site would go down every hour on the hour for significantly longer than this outage. During that time I never received any phone calls. Why did you call this time?" He simply replied, "It works better now".
We had a kettle; we let it leak: Our not repairing made it worse.
We haven't had any tea for a week... The bottom is out of the Universe.
- Rudyard Kipling
What are legacy systems
According to wikipedia, a legacy system: "Is an old method, technology, computer system, or application program, 'of, relating to, or being a previous or outdated computer system,' yet still in use. Often referencing a system as 'legacy' means that it paved the way for the standards that would follow it." Some examples include an old operating system (Windows XP), web browser (Internet Explorer anyone) or floppy disks (remember those things???).
In essence, it's some software (or hardware) that was very common during a period of time, which has now been replaced by an updated version, newer process or improved system. Many companies have legacy hardware, legacy platforms, as well as legacy applications, many of which are critical for business operations.
For many businesses, they don't know or care about having legacy hardware/software/systems as long as it's all working. So for that reason, there isn't an incentive for them to change, invest time or effort into changing them. If they don't believe it's a problem, it probably won't change. This very fact is what makes having legacy systems so dangerous and why you should retire them as soon as possible.
Our destiny is not written for us, it's written by us.
- Barack Obama
Why are legacy systems so negatively impacting?
- They break
Remember my story about the website that went down every hour on the hour. In my experience, breakage is aggravated and directly correlated to the age of the legacy system. Meaning the older they are the worse they get.
- They are usually security risks
Legacy systems are quite often old. So this means old coding conventions, obsolete ways of doing things, ancient hardware, outdated tools, and programming or scripting languages that are no longer supported. You get the idea; it's a significant risk especially with the rise of things like ransomware.
- They are difficult to change and maintain
As the legacy system decreases in popularity, the labor pool decreases exponentially. People move on or off the project. With less resources and expertise, undoubtably this causes a downward spiral. Less updates, fixes and refinements, all add up over time to create more and more problems within the system itself. Remember the bit about being a junior developer; legacy systems are not the best place for a new developer, but it happens regularly.
- They are distractions
If you are serious about doing impactful work, the less legacy systems you have or are responsible for the better off you'll be. Doing urgent fixes pulls you away from doing your important work that is going to help move your business forward.
- They can't scale
There is usually an underlying reason why it was once a popular system and then became unpopular.
If after all this, you aren't worried, nothing is going to convince you. If you can't admit you have a problem, you're living in denial.
Leaders are called upon to build not to repair.
- Farshad Asl
How do you fix a legacy system
You need to take action. If you can't convince your leadership to support you, you'll need to personally take complete ownership of the problem yourself to fix it. To do that, you'll need to become a person of action. Here are some suggestions to get started:
- Perform an audit. What was it meant to do? How does it work? Why was it built? Who uses it? Review any existing documentation. If there is no documentation create some.
- Review what tools exist that you currently have or maintain that could replace or supplant it.
- Talk to people using it. You'll gain a lot of insight understanding how they use it. What they do with it, why it's important to them, how it can be improved... and ultimately how you can replace it.
- Build something better. Take the previous insights and create something that will allow you to decommission the legacy system. My approach here is always parity+.
I suggest getting aggressive with your building process. Build a prototype, show it to people, get feedback, rinse and repeat. Even in doing this you might shift the focus from problems with the current system to the new future state.
In some cases legacy systems were built for a very specific reason, and while that was ideal during that time, that's no longer the case. By offering to build something better, without losing the critical features that are actively used and addressing existing pain points you'll find it much easier to transition people off. It's no surprise that you'll have more internal business support by helping to improve the workload of your colleagues.
The purpose of life is to contribute in some way to making things better.
- Robert F. Kennedy
Build and make a positive change
Once you reduced even some of the burden of your legacy systems you create a positive feedback loop. You'll have created new development capacity simply through reducing time-consuming and usually wasteful legacy support. This will allow you and your team to focus on your primary platforms, systems, and future technologies to help you move forward more quickly to improve your business.
This becomes a permanent positive change for the entire team (developers, project managers, product owners, etc.) where by moving these legacy obligations away from your group you are able to spend that newfound time fixing more important problems, learning and exploring unique and novel ideas, which could lead to other business benefits. This gives the team confidence and purpose. By retiring legacy systems and modernizing you amplify your results, capacity and team morale.
All problems have solutions.
- Steven Magee
Final thoughts on legacy systems
You can't purposefully change what you're unaware of. So if you have legacy systems you are responsible for, you need to take ownership and accountability to improve them. As a business leader you set the example and need to do what's best for your team and the business. This means educating and convincing other business stakeholders or managers in your leadership chain of your experience, knowledge and potential risks around an existing legacy system. This is your responsibility and yours alone. You owe it to yourself and your team to make forward progress and remove the burden to both yourself and others imposed by legacy systems. By focusing on retiring, replacing, or transferring responsibility of legacy systems it will make a lasting positive impact on your teams.
Don't avoid or ignore the impact legacy systems has on your team. Take action to fix it by building something better. Newer systems can reduce support requests, allow teams to prioritize, and focus on important business problems, address critical issues faster and allow for positive explorations and learning.