Item — HN Reader

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

1 comments

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.