[reallydude]

> If the requirements change then the code should change.

That's the nature of the term "Legacy", that you are using. It met requirements that are not the same today (sometimes it's just standards of coding). It didn't change, hence it's legacy code.

[davesmith1983]

There is all sorts of wrong here. You are conflating several concepts.

Firstly I was commenting on your very strange definition of what working meant. What we (programmers) normally mean by working we mean "It fulfills the requirement that it was developed against". If the requirements change, the code must change to reflect the changes in requirements. If the software is changed it is a different version of that software.

Legacy has nothing to do with that. Legacy until relatively recently meant "Not supported" i.e. Windows XP is "Legacy" whereas Windows 7 is not.

Consider the scenario:

I am asked to write a program to play sound. So lets make up some trite requirements.

* It be able to play .wav files

* Sound should always come out of the default audio device as designated by the OS.

It is written and released. We will call it version 1.0.0 and it is supported to December 2021.

People ask for more features. These new features are:

* It is able to play .mp3 files

* The ability to choose the audio device that you can play sound through.

It is written and released and it is called version 1.1.0 and it is supported to December 2022.

Now the requirements have changed however because we are still in the year 2019 they are both still supported. However the requirements to the software has changed and thus there is a new version of the software to reflect the change in requirements. That should be related in the change-log (remember those things).

In 2022 version 1.0 will no longer supported. There will be no defect fixes to it, but it still works i.e. fulfills the original requirements as listed above. However under the more traditional definition of Legacy Software it is considered legacy.

Things like code quality, maintainability etc. are separate issues.

[reallydude]

> What we (programmers) normally mean by working we mean "It fulfills the requirement that it was developed against". > Things like code quality, maintainability etc. are separate issues.

That's your characterization and not all how development works in practice. The vast majority of software barely has anything like versioning and a scant few have maintenance/support windows. That's a fact by volume.

Defining the term "Legacy" to mean something specific as a subjective point of reference (since there is no formal definition), eg

> Legacy until relatively recently meant "Not supported" i.e. Windows XP is "Legacy" whereas Windows 7 is not

is helpful, because it lets me understand what you are thinking, clearly. This does not change my position, as my experience is that working code is still called legacy internally, all the time. The historic resource problems with things like broken dependency chains (you can't even build it anymore), or availability of platforms to test on, is common.