Over the years, I have seen the term "legacy" used with different shades of meaning:
- Code without tests, or at least without thorough test coverage.
- Code that runs on old platforms, or in old frameworks, that the organization desires to replace.
- A collection of systems without clearly-separated services and layers.
- Systems/services that the organization wants to expose in a different style (e.g. shift from method-oriented API to resource-oriented protocol).
- Old stuff that the speaker would rather rewrite from scratch than work hard to understand.
- ...and others...
In addition, calling a system "legacy" sometimes is perceived by those who developed (or who maintain) it as code language for "You people aren't good programmers."
So I'm wondering if you can unpack the sense(s) in which you use the term "legacy" and provide specific guidance for each shade of meaning, especially in terms of helping teams that worked on the "legacy" software become active participants in the re-engineering work.
Thanks!