The use case in these discussions is never about framework or shared code. Taking the example of the lookup tables for error messages, imagine if you shipped y

The use case in these discussions is never about framework or shared code. Taking the example of the lookup tables for error messages, imagine if you shipped your framework and lots of teams started using it, then you iterate to change your APIs in a breaking way and suddenly the cost of that change is multiplied by all the teams refactoring. It is also worth considering the cost of changing existing production code, this is typically where most bugs are introduced, especially when someone else is implementing the fix without the domain knowledge of the original author. Unit tests won't help if they also have to be re-written to match the new API, as they are by definition new/different tests. I think writing malleable code is the key takeaway from this article, and if thinking about future possibilities helps with this, then it should be encouraged. Being unable to predict the future doesn't mean you shouldn't anticipate and prepare for change.