Looking at code in our workplace.. I realized one thing. Like Devops, legacy code is actually a mindset.

So here goes my thought:

A piece of code is not legacy because it was written ten years ago.

A piece of code is legacy because it looks like a piece of legacy code.

With the legacy code mindset, you end up writing legacy code no matter where you are, when you wrote it.

I was looking at some part of our code which we written in just the last few months, and I can’t help but think that they were legacy, so it really doesn’t matter when it was written!

It is more about how you write your code that determines whether it is legacy :)

Hopefully this was not crazily confusing anyone. Have a good day guys & gals!

Yep, husband is experiencing this at the startup he's a PE at. Some of the code that gets slung around there is god awful, like really bush league shit; tons of code replication, massive resistance to anything new (they're still heavily invested in Java 8 in what is a brand new set of services). Tons of NIH and golden hammers as well.

On the other hand, our technology is very new.
But we have:
- freestyle node.js + expressjs architecture aka controllers that easily grows over 1.5k lines, with tons of actions and functions blended in
- very DRY libraries/functions that accommodate every use cases. (Think of it as a gigantic if-else handler)

So my point is.. time probably isn’t a factor here. It is regardless of when the code is written, or what technologies/frameworks are used and how old these tech has been around, but rather the way it was written, whether it is using the proper design patterns, and written in a way that is highly readable and easily scalable, etc.

@skyrocker so true. A legacy coder can write legacy code in any language, any platform using any pattern :/

Had one such colleague for many years, he reinvented the same bugs and problems no matter what new tech he learned, and he did learn new things, just not new ways.

When someone writes legacy code in modern times, we probably shouldn’t call it legacy but just bad code

I'm cursed with good memory. Why a curse?
because everytime someone in my company stumbles on legacy code, that did not change in the last 6 month, they come to me for help....
I have to explain the reasons behind the shit code everytime. Go over what needs to be done for the minimal change required, and give a reason why not to refactor the mess (not enough time in the multiverse).

So yes - shit code is shit code.

@bruterik problem is that in many cases you cannot see the difference, if it walks like a duck.

And even if it is considered bad code today it sometimes wasn’t bad code 20 years ago in a different language.

It might not have been good code, but working acceptable code.

Programming languages, and hardware, has come a long way and many old practices are not relevant or even bad by todays standards.

So legacy code is not directly synonymous with bad code, and sometimes its not really bad, just legacy.

Ok code can become legacy very quickly if you don't test it, put devs that don't care on the team and let it all be guided by execs that think "if it works it's not broken". Pile up tech debt until there's no room to breathe.

I changed teams to escape from hell like described above exactly. I saw in the emails since Friday they have been losing a lot of revenue because the system times most the requests out and randomly fails performance tests. That affects k8s and the scheduler kills pods or restarts them 100s of times. All services downstream suffer. Massive severity of an incident. No one knows how to read the code and how to fix it. Previous lead allowed copy paste engineering and brute forcing changes so there we are. Happy not my problem anymore 🙂

I have been saying while on that team that this tech debt will bite our asses very badly one day but no one listened. So I fucked off 🤷‍♀️