A Legacy Application Has Born

One thing I've seen over the years working in multiple projects is the high amount of unneeded complexity in the technology we choose to develop our applications.

Complicated build systems, an unbearable e2e test suite that takes ages to understand, super complicated abstractions to deal with data... you name it, we are surrounded by complexity in all the layers of our technology stack.

Complexity is the root of all evil

So why and when we reach this complexity? This is the result of our own technical decisions, we often choose solutions that are more complex than the problem we want to solve and in result it ends up adding more complexity that's left behind for other people to deal with.

Technical debt is the gift a developer leaves for the generation of programmers that come after.

But, anyway, How is this related to the title? I'm here to talk about how a legacy applications are born.

Yes, as you might have guessed complexity is the primary driving factor of when a legacy application is born. The moment an application complexity is way higher for your team to deal is the moment a legacy application is being born.

It starts when the people that originally built the application, which were the ones who could "manage" this complexity leave the company, leaving the team without the necessary depth of knowledge to maintain it properly.

This starts the downward spiral of despair, no one wants to touch it, adding features seems to take ages, it's hard to find talent that wants to work on it, migrating to a different technology is expensive and complex. Congratulations a legacy application has born.

evil-baby-doodle.png

Choosing the right amount of complexity

So, what can you do? Ask yourself, is this the right technology for the problem at hand?

Our actions have a very deep impact ramifications for people who come after us for developing our systems and maintaining them.

Sometimes a boring programming language is a better decision that a very modern language with unfamiliar semantics, sometimes a rails app is better than a swarm of microservices/serverless functions, sometimes a small amount of e2e tests is better than testing all possible scenarios.

We are in charge of dealing with complexity, every application will eventually be a legacy application. But, if we don't spend the time and effort to remove it, a legacy application will certainly be born.