Comment by WD-42
6 days ago
This definition doesn't make any sense to me. If code at an org is working, and there are people or at least a person at that company that understands it, how is it legacy? Just because it's been around for a while? At what age according to your definition, does perfect working code that can be improved or added to by currently employed developers, become "legacy"? I feel like you are falling into the "keeping up with the Jones'" trap.
I much more agree with the blog author. Once the last developer that has a deep understanding of a codebase moves on (or simply forgets it all), that's the point it becomes legacy.
The problem with the definition is that if a business has some ancient COBOL code with one guy left who understands it, then your definition would say that is not legacy code. And that is what makes no sense.
It becomes legacy when it is no longer running on a tech stack that matches the future strategy of the organization. Legacy is a strategic label, not an engineering label. There is no age where something becomes legacy, it happens when business strategy moves on to something else.
Okay, I could get behind that definition if you could tell me what you call code that aligns perfectly with the "strategic future of the organization" but nobody at said company understands or can work on?
Critical magic
It becomes legacy once the organization understands that the codebase, or platform, or business case, is obsolete. It does not mean it's immediately phased out; it may continue working for decades more with some love and attention, but it's clear that it is in the past rather than the future. The easiest way to tell if a project is legacy is how desirable it is for programmers in the company to work on.