Hacker News Reader

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.

I wouldn't get too persnickety about definitions. There are lots of arguments about what 'legacy' code means. you are throwing around the term quite a bit without really giving any definition at all. 'Code that nobody understands' is fine as a quick and dirty pointer.

Martin Feathers, in the most popular book on legacy code, defines it as code without tests. This is not a good definition at all, but it shows just how hard it is to define it. This is not meant as an attack on anyone: I just think some flexibility and slack is called for here.

You could easily write an long white paper trying to define 'legacy code', and it would be a lot less interesting than the target article here.

The post is trying to define vibe coding, so the definition of things is highly relevant.

I didn't get out of the post a focus on definitions as the main point. I got out of the post a concern about massive technical debt, which is the hallmark of both legacy code and vibe coding. And no, I'm not offering a definition.

> People do understand it. Often, deeply understand it because they wrote it, and have lived and supported it for years. They know the reason behind the tech debt, all the odd tech constraints that drove it to where it is, they can keep the thing running without breaking a sweat. It is second-nature to them.

I don't think it counts as legacy code if the original devs are still around to work on it

Legacy is not just "old" it is something that was left behind by someone else

Peter Principle for codebases - codebase will continue to grow until nobody understands it, and then it will tread water until enough key personnel leave and then suddenly eng capacity is below the cost of servicing the debt and this is the point at which all control is fully lost. Eventually a younger sharper competitor will acquire it for the users or it will go through M&A repackaging or some other way to extract the last drops of money before discarding it

> People do understand it. Often, deeply understand it because they wrote it, and have lived and supported it for years.

You're assuming the people that wrote it are still there, which is often not the case.