[reallydude]

> Legacy means it worked.

No and shame on you for pushing this idea, is my first reaction. "worked" doesn't mean anything.

Positing this redefinition of Legacy (and implying what "worked" means) rubs me the wrong way, especially when tying it to the idea of code ownership. Maybe I just have a warped perspective, except that I've run into these scenarios.

"worked" might mean "it was easy to fix and it broke a lot", "it calculated the numbers correctly but nobody knows how to change it without it breaking", or "it costs $5k a run but it gives us the right count of a database column". Legacy means it might be working, depending on your CURRENT needs. Your current needs change, even when the code does not.

Code ownership isn't at a single level, which makes some of this analysis seem idealistic.

[stahnma]

Author here.

Code doesn't become legacy if it didn't fulfill some purpose. If it didn't work, it wouldn't be legacy, it'd be source code in somebody's home directory that was never deployed.

All working software is not legacy software. All legacy software (still running) works, for some definitions of works.

That's not to say your points aren't also really correct. Software is built with current requirements and knowledge in mind. Best decisions with info we have..etc.

[davemp]

I know of at least three projects (with huge budgets) right now that are spawned from the corpses of old, failed projects that never worked. Those old projects make up the legacy of the current effort and can’t be easily thrown away.

[davesmith1983]

> Legacy means it might be working, depending on your CURRENT needs. Your current needs change, even when the code does not.

No working should mean "It fulfills the requirements". If the requirements change then the code should change.

The other things you have mentioned are important but they aren't necessarily requirements e.g. Uptime / Reliability / Performance might be requirements but without stating what they should be you can't say that a piece of code doesn't work if it "slow".

This sort of stuff is real basic software engineering.

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

[jackewiehose]

> "worked" doesn't mean anything.

"worked" means it gets the job done and legacy means it's old. Code only gets old when it worked (at some point). So I don't think this redefinition is that far off.

[davesmith1983]

I think they are referring to the fact that "Legacy" has now been defined as code without unit tests in some circles.

However I agree in general most people mean "Old code I don't want to work on because I don't like the technology it is built in".