This is a great way of putting it! It's true that many middle managers and business/sales people do not respect this line of reasoning, but that is their mistak

This is a great way of putting it! It's true that many middle managers and business/sales people do not respect this line of reasoning, but that is their mistake rather than a genuine or well thought out business decision -- which is why it bites them in the end. I would take this further and say that it's often a matter of professional disrespect to pay the architect's skepticism such little heed as to override the architect's vote to constrain feature creep. Self-discipline is hard! One of the most challenging aspects of this in real development jobs is that shrewd managers and/or business and sales workers are very good at deflecting blame and creating political situations in which they are able to pretend to have supported the "right" choice no matter what the outcome. So, very often, when features get hacked into the system against the architect's advice and it predictably causes untenable debt growth and parts of the system fall over, what is the first thing you hear? That it is the engineers' fault for not building the system correctly. It's very rare that an architect can successfully communicate the problem of excessive feature growth and convey after a system failure that it was not really the engineers' fault, rather the fault of everyone forcing their poorly conceived features to take priority. In a healthy development environment, everyone should be hearing "no" very, very often when asking to add features, especially when they come to you as if it is a big emergency that some market phenomenon mandates that the feature must be added right now. If you find yourself in an environment where your employer does not empower you, as a developer, to say "no" in that situation definitively, then rather than trying to fight any blame wars about whose fault a system failure was, just get your resume ready and leave. There's no need to put up with that sort of poor engineering culture, and plus, wouldn't you rather put your name on something of quality instead?