Been having this fight a lot lately. The phrase that seems to have struck a chord is ye olde "first you make the change the easy, then you make the change". As

Been having this fight a lot lately. The phrase that seems to have struck a chord is ye olde "first you make the change the easy, then you make the change". As a further elaboration, I'm trying out that this gets you: - Better position. Code's better, so product is better (more stable, with better features, etc) - Higher velocity. Each time you do this, the overall codebase gets easier to change, because you're continually making it easier to change - High acceleration, because you're giving your devs a way to stretch their capabilities and grow their skills. Definitely gonna see how "Refactoring has a price. Not refactoring has a cost. Either way, you pay" plays with folks! PS - AFAICT, future proofing is bad when you build stuff to aim it, mostly because you probably won't end up with the problem you think you will, so you're not actually able to build it correctly now. But! You can build in gaps, for where that new stuff can go. You can future proof pretty much only by writing your code today with eye towards making unknown changes later - ye olde "the only architecture that matters is the one that lets you change".