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 MAN

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)