6 ms·

That's not really a popular or even useful definition. According to that author, a Go microservice I wrote yesterday would be legacy code, while a 25 year old T

That's not really a popular or even useful definition. According to that author, a Go microservice I wrote yesterday would be legacy code, while a 25 year old Turbo Pascal scientific instrumentation program running on MS-DOS, which some poor soul still has to maintain is not, because the programmers wrote a few tests for it back in the day?

davidjnelson 7y ago
Interesting. Is your definition of legacy code “code that was written <x> time period ago”? Wikipedia defines legacy code in several ways. So sure, that term has multiple meanings. Code without tests is a definition mentioned in the “modern representations” section. Wikipedia indicates the original meaning was code that was dependent on a deprecated underlying foundation such as on os / framework / etc. This is a snippet from the “modern representations” section of the Wikipedia entry. Basically the idea is legacy code is code that is hard to change: “Eli Lopian, CEO of Typemock, has defined it as "code that developers are afraid to change".[1] Michael Feathers[2] introduced a definition of legacy code as code without tests, which reflects the perspective of legacy code being difficult to work with in part due to a lack of automated regression tests. He also defined characterization tests to start putting legacy code under test.” https://en.m.wikipedia.org/wiki/Legacy_code https://en.m.wikipedia.org/wiki/Legacy_code
goto11 7y ago
Correct, because the Turbo Pascal program can be safely modified and extended. If the need arises you can port it to a more modern environment. Code without any tests can't be modified without risk of unexpected breakage, so it is basically legacy the moment it is written.
- joefourier 7y ago
  Having tests is not a panacea. There's no guarantee that any of the tests are automatically well-written - they could be too narrow in scope, overly brittle, or be so numerous that each minor change requires hours of automated testing, making progress a huge chore. That's not to say you can even run, let alone compile some legacy code without a large amount of effort. That's the whole point of the term, that they rely on obsolete, unsupported or just ancient OS, hardware or platform, often requiring emulation, special development environment. Redefining it to mean "code without tests" just confuses things.
  - goto11 7y ago
    To me "legacy" means when you are stuck with something outdated. Code is not legacy just because it is old, it is legacy if it can't be adapted to changing requirements. For example old mainframe systems where the source code has been lost. Code can be brand new and on the most fashionable platform, but if it is undocumented and unmaintainable and the original developer is unavailable - then you have legacy code. Because you are stuck with it and can't keep it updated. If on the other hand the Turbo Pascal program runs fine and you have test coverage which allows you to refactor and adapt to changing requirements - what is the problem? And if you want to port to a more modern environment or platform you can do that with low risk. Of course tests can be badly written, that goes without saying. Nothing is a panacea - not even microservices in Go!

davidjnelson 7y ago

Interesting. Is your definition of legacy code “code that was written <x> time period ago”? Wikipedia defines legacy code in several ways. So sure, that term has multiple meanings. Code without tests is a definition mentioned in the “modern representations” section. Wikipedia indicates the original meaning was code that was dependent on a deprecated underlying foundation such as on os / framework / etc. This is a snippet from the “modern representations” section of the Wikipedia entry. Basically the idea is legacy code is code that is hard to change: “Eli Lopian, CEO of Typemock, has defined it as "code that developers are afraid to change".[1] Michael Feathers[2] introduced a definition of legacy code as code without tests, which reflects the perspective of legacy code being difficult to work with in part due to a lack of automated regression tests. He also defined characterization tests to start putting legacy code under test.” https://en.m.wikipedia.org/wiki/Legacy_code https://en.m.wikipedia.org/wiki/Legacy_code

goto11 7y ago

Correct, because the Turbo Pascal program can be safely modified and extended. If the need arises you can port it to a more modern environment. Code without any tests can't be modified without risk of unexpected breakage, so it is basically legacy the moment it is written.

joefourier 7y ago
Having tests is not a panacea. There's no guarantee that any of the tests are automatically well-written - they could be too narrow in scope, overly brittle, or be so numerous that each minor change requires hours of automated testing, making progress a huge chore. That's not to say you can even run, let alone compile some legacy code without a large amount of effort. That's the whole point of the term, that they rely on obsolete, unsupported or just ancient OS, hardware or platform, often requiring emulation, special development environment. Redefining it to mean "code without tests" just confuses things.
- goto11 7y ago
  To me "legacy" means when you are stuck with something outdated. Code is not legacy just because it is old, it is legacy if it can't be adapted to changing requirements. For example old mainframe systems where the source code has been lost. Code can be brand new and on the most fashionable platform, but if it is undocumented and unmaintainable and the original developer is unavailable - then you have legacy code. Because you are stuck with it and can't keep it updated. If on the other hand the Turbo Pascal program runs fine and you have test coverage which allows you to refactor and adapt to changing requirements - what is the problem? And if you want to port to a more modern environment or platform you can do that with low risk. Of course tests can be badly written, that goes without saying. Nothing is a panacea - not even microservices in Go!