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...
But even in a broader context, I think a lot about how to capture things like "the reason this code is this way is because when we wrote it platform didn't have support for X, it now does but in a very different way and adapting to that requires some non-trivial effort"
Which requires both knowledge of the past, the present and some speculation about how important such details will be in the future.
@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.
