Every software developer who has spent more than a few weeks on a project has at least one experience in common. You find yourself reading through a file, scratching your head, trying to figure out what the author was thinking. When you finally get to that “aha!” moment, it can come with feelings ranging from confusion and frustration to awe and respect, and so on. However, there is one skill I try to practice in these situations: empathy. This is especially true when working with legacy code.
There are already guides for how to practically walk through and understand legacy code, or add automated testing. So I thought I’d discuss what I keep in mind when working with legacy applications and how they help me understand why these projects are the way they are and empathize with the author.
Software developers are smart.
First, it’s best to operate under the assumption that the code’s author was at least as smart and competent as you are. This one should go without saying, but it’s the bare minimum requirement for the rest of these practices. If you’ve worked alongside other developers and studied computer science, you should be well aware that this industry is saturated with brilliant people.
To take a project from idea to implementation alone is no small feat. Navigating an ever-changing landscape of technologies and system architectures, balancing stakeholder priorities, and getting a working product out the door can be a monumental task. The original developers managed that and built something that has survived for five or even 10 years. So, I think it is safe to assume they at least had some idea of what they were doing.
It’s still working.
That brings me to the next thing I try to keep in mind. That this code is still live in production is a testament to how well it is doing its job. At the end of the day, we are not writing code to publish and admire for its beauty. We are trying to solve a problem. Any developer would be proud of building a project that could stand the test of time, especially in an industry as fluid as this one.
If a project is still running and serving a purpose, then we should respect the thought put into it. Time is one of the best evaluators of software. And, for legacy applications, it’s the best proof of value.
You weren’t there.
This brings me to what I think is the most important thing I remind myself of when working on a legacy application. Whoever worked on this in the past made the best decision they could with the information they had at the time. There are a lot of forces that shape software, and not all of them are technical. When working on a project, we’re often faced with decisions that have no right answers. We have to make a decision based on what might happen in the future. Maybe it’s the direction the business will shift or the availability of talented developers in a tech stack. Or it could even relate to the expected lifetime of a third-party package we’re going to use.
Without the ability to predict the future, we are stuck making decisions based on our best guess. Remembering that the person who made this decision was smart, talented, and forward-thinking, it should be obvious that they made the best decision they could with the information they had at the time.
What can we do now?
So, we’ve decided the previous developers of a project were smart and talented, the code is still being used today, and the developers made the best decision they could at the time. Then, I think It’s clear that whoever worked on the project shared Atomic’s core value of thinking long-term. This brings me to my next assumption: Assume they made their choices for a reason.
There can be a lot of confusing code in a codebase that has been around for a few years, but one thing that can help demystify it is continuing to ask yourself, “Why?” Figuring out why things are the way they are unlocks the most important question when refactoring or rebuilding. Is the reason for this still valid? Developers often make decisions based on imperfect knowledge, but we are fortunate enough to see how well those decisions withstood the test of time. As we move the system forward, we can use this information to inform the direction we head in today.
These assumptions and understandings have helped me immensely throughout my career. I hope they will help you the next time you find yourself working in a legacy code base.
I don’t agree with the premise “Software developers are smart”. Many are, but many are not. Over the past 2 decades I’ve seen some terrible code written by people that had no business being a software developer but because they were barely smart enough to code they put together a ball of mud that barely worked but wasn’t maintainable or understandable. People dread legacy code for a reason and that reason is usually that someone that had no business writing complex software did so.
I’d like to start off by pointing out that I was presenting that as an assumption I choose to make. Even if you disagree with that assumption, you have to give credit to some member of the development team for building a project that is still around. Legacy code only becomes legacy by continuing to solve a problem for the business. There are a lot of reasons a project can become a ball of mud, and I think blaming it on the original developers intelligence is a convenient way to avoid figuring out how the business has changes trying to make it better.
Another reason developers may make a technical choice is to try out a new feature or follow a fad. “Hey, let’s try putting JSON in a database field”. “How about we try this new language.” “Let’s use database triggers so we don’t have to code the business logic”. It may have seemed reasonable at the time. Empathy may need to be applied to the developer, not just the code.
To add what you are saying, we as we look at the code might not understand the business logic trying to be implemented. We then have to find the person that does know, or hunt down the requirements for that bit of code. Finding the requirements can be a task within itself now cause teams change from platform to platform so frequently now it seems.