> (why code that had been dead for 8-years was still present in the code base is a mystery, but that’s not the point).
Actually it's a big part of the point: they have a system that works with dead code in it. If you remove that dead code perhaps it unwittingly breaks something else.
That kinds of chesterson's fence is a good practice.
Chesterton's Fence states that you shouldn't make a change until you understand something's current state. Removing code because it's dead is folly, if you don't understand 1) why it's there, and 2) why nobody else removed it yet.
As this is a postmortem, it was proven dead code. There is nothing in the text that mentions that they didn't know what the code did (which then wouldn't be dead code).
It may not be obvious that it's dead code - in a lot of popular interpreted languages, it's impossible to tell if a given function can be called or not
Your original comment is somewhat unclear. Are you advocating for leaving old code in because the system works and it's more stable that way, or taking it out to force the necessary refactoring steps and understanding that will bring?
I'm sorry I wasn't clear: I re-read my comment and couldn't think of a decent edit.
It was the author whom I was quoting as saying "why would someone have old code lying around." It seems obvious why that's a good idea and it seems commenters in this thread (including you) agree with me and not the author.
Actually it's a big part of the point: they have a system that works with dead code in it. If you remove that dead code perhaps it unwittingly breaks something else.
That kinds of chesterson's fence is a good practice.