So a project that's still using Java 1.6 and has perfect test coverage and some poor developer is paid to maintain it (but NOT upgrade it!) is not "legacy" in your book?
Then we disagree on the definition.
"Legacy" projects to me are those that should've went through at least two generational refactorings but haven't because of some unfathomable reason. These are the ones that eventually end up being rewritten from scratch because it's faster than trying to upgrade the 25 year old turd.
> So a project that's still using Java 1.6 and has perfect test coverage and some poor developer is paid to maintain it (but NOT upgrade it!) is not "legacy" in your book?
If a project is perfectly maintainable and developer teams are confident they can roll out any change they see fit with total confidence without having to risk nasty regressions or work around any pain points, then obviously it is not a legacy project as per definition.
If instead you have services running on Java25 that you can't touch a code path without breaking it or knowing it broke, that is a legacy project.
It is not about the age of a framework. It's about the ability to maintain it. Legacy is synonym with being unmaintained and unmaintainable. Not age.
If someone maintaining a project that's 25 years old and hasn't had a complete overhaul is "confident" about anything, they must be the one who originally wrote it =)
At least that's my experience. Anyone else brought in during the last 5 years is usually terrified of changing anything because there are so many obscure corners and dependencies nobody can predict before stuff just breaks down.
> If someone maintaining a project that's 25 years old and hasn't had a complete overhaul is "confident" about anything, they must be the one who originally wrote it =)
You are failing to understand that the key factor even in your example is maintenance, not age. You can and often do have legacy projects that use the latest and greatest frameworks. That's not the differentiating factor.
> At least that's my experience. Anyone else brought in during the last 5 years is usually terrified of changing anything because there are so many obscure corners and dependencies nobody can predict before stuff just breaks down.
The obscure corners and dependencies are the output of lack of maintenance, not age. That's why you can and often have brand new projects that are unmaintainable, and dismissed as legacy.
I've predominantly worked in two industries, healthcare/public health and insurance where policies terms are measured in decades. The software for both ranges from 20 to 40 years old, and it hasn't been upgraded because to do so poses an existential risk to either the business or, in the case of healthcare, to human life. Upgrades are measured in terms of human generations because of said risk, but I wouldn't call these systems legacy due to not moving beyond java 1.6.
Then we disagree on the definition.
"Legacy" projects to me are those that should've went through at least two generational refactorings but haven't because of some unfathomable reason. These are the ones that eventually end up being rewritten from scratch because it's faster than trying to upgrade the 25 year old turd.