More and more I think it best to think of software projects as a collection sedimentary layers, building on top of each other.
With the write investment you can remove or replace a layer, but the deeper it is the more expensive and structurally difficult it will be.
I wonder if and how tools and techniques from stratigraphy and archaeology can or have been adapted in the aid of studying such structures.
It's also why I don't particularly think rewrites are a bad idea if considered in the right context.
A lot of rewrites fail because they only assess the surface of a system and neglect the foundational and integrational knowledge that builds up over the lifecycle of a project.
But that kind of knowledge can be analyzed and should be re-assessed - maybe you really don't need all that platform specific code now that the latest version of dependency C has better lifecycle awareness...
@sarahjamielewis You're right.
That's why I think *requiring* in-code documentation that also details: context, intents, thought processes and arbitrages, instead of only comments that are a barely-more-human-readable summary of what code does, is very important. But that's not where the culture is leading right now.