3 ms·

thanks for reading! I use legacy code as in "code that was written yesterday or earlier", or in a less jokey fashion as "code that noone really feels ownership

by larve 4y ago

thanks for reading! I use legacy code as in "code that was written yesterday or earlier", or in a less jokey fashion as "code that noone really feels ownership for", usually a codebase that shows the sign of many developers, repeated cycles of outside pressure. What I mean by "product performing well" is that the legacy codebase is still alive for a reason: it is doing its job and the job has value. Otherwise it can just be cut and deleted (a very pleasant refactoring technique, I must admit).

tpoacher 4y ago
Yes, I got that. I didn't feel that the "alternative definition" was offered disingenuously, but it's still a problem when you want to have a discussion and you use certain commonly accepted terms, but with a different definition in mind. Imagine if I talked about "democracy" and in my mind I meant "The Athenian model that only allowed men over the age of 30 to vote", when everybody else was talking about, well, democracy. In case you're not familiar with the book (i.e. "M. Feathers, 2004. Working effectively with legacy code."), it is a classic and widely regarded as "The" book on how to approach legacy codebases (even if a bit dated by now). A highly recommended read. It was also very enjoyable to read, which is remarkable for an otherwise technically-oriented book. Here is the relevant except from the introduction, defining what legacy code is and why it's a problem: > In a strict sense, Legacy code is simply code you've gotten from someone else. However, clean, easy to work-with code is rarely referred to as 'legacy' code; the term usually implies a tangled, unintelligible structure, difficult-to-change code that is difficult to really understand. Therefore, a more pertinent description is: > > Legacy code is where any of the following questions fail to apply: > > - Is your code easy to change? > - Can you get nearly instantaneous feedback when you do change it? > - Do you understand it? > > If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts. Further down, he offers this simpler, provocative definition, which introduces the main theme of the book: > Legacy code is code without tests: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse. In a more modern setting, presumably 'tests' would be extended to include other good software engineering practices, like version control, CI, etc. But the book's theme still applies in the more general since, so it's still relevant today. If you've not read it, then pick a copy up, you're in for a treat :)
- larve 4y ago
  I definitely studied that book when it came out. I feel my definition is the same as his "Legacy code is simply code you got from someone else". I have seen MANY legacy codebases with tests. Surprisingly often these tests are not only useless, they were partly responsible in reifying horrible wart-patching on top of an outdated abstraction, as replacing the abstraction as requirements changed would have required a new test suite. As I'm gaining more experience tackling project from a business perspective, when encountering a legacy codebase, it makes sense to start reviewing the business assumptions. Does this codebase even make sense in view of the current business strategy? If not, there's probably big chunks of code that can be entirely "written of", yet need to be kept alive long enough to migrate without disruption. Unit tests can help, but I often found deleting the unit test suite and starting a new one a more productive approach (again, with my experience of 6-7 projects). But we agree. The book is a bit out of date, and it's focus on approaching the problem using 2004 agile techniques is not something I would fully recommend anymore, but I have yet to find a replacement (maybe there is one out there, I haven't looked recently)

by larve 4y ago

tpoacher 4y ago

Yes, I got that. I didn't feel that the "alternative definition" was offered disingenuously, but it's still a problem when you want to have a discussion and you use certain commonly accepted terms, but with a different definition in mind. Imagine if I talked about "democracy" and in my mind I meant "The Athenian model that only allowed men over the age of 30 to vote", when everybody else was talking about, well, democracy. In case you're not familiar with the book (i.e. "M. Feathers, 2004. Working effectively with legacy code."), it is a classic and widely regarded as "The" book on how to approach legacy codebases (even if a bit dated by now). A highly recommended read. It was also very enjoyable to read, which is remarkable for an otherwise technically-oriented book. Here is the relevant except from the introduction, defining what legacy code is and why it's a problem: > In a strict sense, Legacy code is simply code you've gotten from someone else. However, clean, easy to work-with code is rarely referred to as 'legacy' code; the term usually implies a tangled, unintelligible structure, difficult-to-change code that is difficult to really understand. Therefore, a more pertinent description is: > > Legacy code is where any of the following questions fail to apply: > > - Is your code easy to change? > - Can you get nearly instantaneous feedback when you do change it? > - Do you understand it? > > If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts. Further down, he offers this simpler, provocative definition, which introduces the main theme of the book: > Legacy code is code without tests: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse. In a more modern setting, presumably 'tests' would be extended to include other good software engineering practices, like version control, CI, etc. But the book's theme still applies in the more general since, so it's still relevant today. If you've not read it, then pick a copy up, you're in for a treat :)

larve 4y ago
I definitely studied that book when it came out. I feel my definition is the same as his "Legacy code is simply code you got from someone else". I have seen MANY legacy codebases with tests. Surprisingly often these tests are not only useless, they were partly responsible in reifying horrible wart-patching on top of an outdated abstraction, as replacing the abstraction as requirements changed would have required a new test suite. As I'm gaining more experience tackling project from a business perspective, when encountering a legacy codebase, it makes sense to start reviewing the business assumptions. Does this codebase even make sense in view of the current business strategy? If not, there's probably big chunks of code that can be entirely "written of", yet need to be kept alive long enough to migrate without disruption. Unit tests can help, but I often found deleting the unit test suite and starting a new one a more productive approach (again, with my experience of 6-7 projects). But we agree. The book is a bit out of date, and it's focus on approaching the problem using 2004 agile techniques is not something I would fully recommend anymore, but I have yet to find a replacement (maybe there is one out there, I haven't looked recently)