> 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 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.