The Path Through Legacy: Delicate Balance Between Tolerance and Phobia

Hi, my name is Max. Today we will talk about the legacy. First, a couple of words about our projects. In Teotihu, Kazakhstan, Altel Digital, we developed four main mobile apps, more than 10 web applications, and more than 150 microservices.

Let's talk about good old essential problems. What is legacy? It can be some ancient architecture, maybe board game cases. Everyone left their legacy path in this world. It works in both ways. Stickers on your board game map or your package cross-dependency in React project. Well, both legacy board games and legacy codes share the same commonality of passing the down something from the past. The nature of their legacy is entirely different. Legacy games built upon previous iterations to create a unique and personalized gaming experience.

So what is legacy code anyway? You might fall into the trap of thinking that it's just an old code. Yes, it can be old. But old code is not necessarily considered legacy just because it's old. With this approach, your own very code you wrote yesterday is legacy by now. Next or following characteristics might seem familiar to you. The answer that we write code which most likely ends up as legacy is outside of the actual coding process and implementation aspect. If you are making your own small project or startup, you are more likely to write fast and revisit later. Nowadays if you haven't taken this route as a small team or one-man army project, you most likely don't have a business. The key is acknowledging the problem in time to move the practical ways of combating the problem. Unfortunately, there is no such instrument in software development like MagiKwan or Sword of Thousand Truths to make everything we want perfectly. But just as weapons and mana bars are tools to success in gaming experience, standard commitment is essential for using technology effectively and responsibly.

As developers we find the idea of rewriting because it's easier. At least, that's what we think. It's easier to judge code written before us and think we have a better solution, often ignoring the business logic that old code serves and what edge cases it was trying to solve. While I tend to believe that rewrite is often not necessary, there may be certain circumstances where it is justifiable. For instance, if a particular section of a project has reached its limit and further expansion requires complicated hacks or workarounds or if certain components are no longer in use and can be isolated, starting anew may be the best course of action. Documentation is one of those things that all developers agree but few do. At least in a practical and efficient way.

You can write an endless amount of disorganized, outdated mess which makes it incredibly hard to update. It's far easier to write lots of mindless documentation. Some say code base can be documentation by itself but having small number of links and anchors in your repository can be a thing. It's pretty much an art in and of itself.

A piece of code might work but it's not useful if you can't extend it. Sure, it can work as expected and still generate profit for the company but one day it can break the entire business workflow. We can minimize the problem by keeping things isolated so it doesn't affect the rest of the code. This can be a permanent solution.

Usually when you write new stuff they will depend on some legacy system, depending on the size, the larger the size of the code base the more challenging it will be to fix it. So, optimizing your code for change and making it easier to delete ironically makes it easier to extend in time and you will not produce legacy code today. Remember what I told you before. The code you write today is old code by tomorrow. Is your intention to be the most clever or is it to help all other future developers that will probably come long after you are gone? Our task is to leave the code base in a bit better condition than it was found. Rather than following best practices, it is preferable to prioritize creating code that is easily modifiable by others. The goal here is to slowly make incremental changes on legacy system.