I manage a highly complex AI service, and from time to time make config changes, and part of that duty is config cleanup -- removal and simplification. This is a necessary job in the past I have found copy-pasta where settings overrides for one environment are incorrectly copied to a similar one, leading to bad customer experience. As a personal policy, before submitting the cleanup PR, I go back in git history to when the config was introduced to understand why it was done the way it was, in case I am missing something. I call this "paying the Chesterton Tax."

Usually its fine, though once in a while the original author gets annoyed at second guessing their work long after it was considered settled. One recent curious example was when I found a specific setting was applied for one out of a set of many similar subservices; when asking around for why only one of them got it when the current data suggested all subservices would benefit, a senior "architect" got annoyed with me asking questions. As best I can tell: the project was shelved after a few months when the architect solved the primary issue and got bored with it / delegated the polishing touches to a junior engineer who went on maternity leave shortly after. Which is a fine enough explanation for me to proceed, but nobody's eager to admit such social causes.