Isn't the implicit argument for any refactor/rewrite essentially increased velocity? "This change will allow us to do X in Y days when normally it would take s

Isn't the implicit argument for any refactor/rewrite essentially increased velocity? "This change will allow us to do X in Y days when normally it would take some multiple of Y." It sounds like what you want is a more salient list of pain points in the current development environment and exactly how the proposed new thing would address them. Additionally, you'd want to hear the new set of pain points that the new thing will impose (cue the quote about some devs knowing the value of everything and the cost of nothing). You may also, for their benefit, direct the next kid with the cool idea towards a link that's commonly thrown around here: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence I'm going to pull the more direct section "What this means on Wikipedia": > If you're considering nominating something for deletion, or changing a policy, because it doesn't appear to have any use or purpose, research its history first. > You may find out why it was created, and perhaps understand that it still serves a purpose. > Or if you do feel the issue it addressed is no longer valid, frame your argument for deletion in a way that acknowledges that.