DEV Community


We are getting used to work with "Legacy Code"

Software Developer since 1999, polyglot programmer, engineering specialist information and agile processes. Degree in data processing and analysis and systems development.
Updated on ・3 min read


In work days we often don't have time for improves our stack and platform because of the business that we have to run to pay the bills and the product is almost more important then the platform that we are building.
Especially if you are working in a startUP the rush to prove values is indispensable.

This can cause a big Headache because in this case we are building a huge six mouth code base legacy if we don't look to the application with care.

Recently I stepped into this scenario, I was working with a bunch of technologies and everything was good, until the day that I realise the some of the applications was using deprecated and unsupported packages. With out time to investigate I just take a look into the problem, that was a bad decision.

I found a big list of vulnerability and gaps in the architecture that gap was letting us without logs, and it was overlapping background jobs.
decide to brake the rules and fail our "Scrum Sprint" to solve this issues but I got a Big fat NO! from the product team and my own team, because we were in our commitment and fail sprint to solve a technical issue could cost the trusty from the Stakeholders.

I'd accepted the team decision because we are a team, but I ask for help to others teams to solve this issues without success, because every team was dealing with their own commitment and don't have time for this.
Well, ladies and gentlemen we are building a huge six months code base legacy.

That's fine for that moment don't reason about that issues, until the day that we actually facing the effects of the issue, when we are trying to debug a production problem without logs and spend a few days on it.

It was time to check the issue out and the whole team not just my squad, decided to fix it. But unfortunately it was too late. We let this go for too long and the fix cause a bunch of work with a several teams. time that could be saved if we have fix the issue earlier.

The most of time, we work with other people code, improving and maintain it and it's normal to us, look at the code that we writing in the moment. Yeah we do our best with that, Write clean code, create unit, integrations tests to make sure that our code is working properly, but, sometimes it just hard to look forward especially when you don't have time.

What we all need to remember is that is our responsibility to refactoring and fix gaps codes, because one day, we will face this gaps again.

It is easy to say that, but how we can actually fix this in day by day?

  • Starting with the real value of your software.
    Don't try to create a elegant code that took a lot of read to understand.

  • Planning every step that you will do.
    You need to reason for every single task that have to be made before you actually work on it because, when you don't know exactly what is your job, There is a good chance of you put some bugs in there.

  • Testing the whole application.
    Beyond your feature, there is a application and you need to ensure that is everything is working perfectly right.

  • Don't be shy - Communicate yourself
    You know that moment, that you realize that you will not gonna make it?
    It can be because a problem that that nobody saw, personal problems, or something else. You must ask for help!

  • Don't forget your code on production
    I think this is the most important item of this list, once we have finished our
    feature, we pass to another feature/product, but we can forget our code. we need to look into it's behavior to make sure that everything is good.

There is a lot more but this is the basic things that you can do to avoid creating a legacy code.


Discussion (0)

Forem Open with the Forem app