I understand the feeling, and used to share it more before I became a bitter old man with corporate responsibilities and a hatred of all spontaneity and joy. B

I understand the feeling, and used to share it more before I became a bitter old man with corporate responsibilities and a hatred of all spontaneity and joy. But constant changes can be a hassle for a lot of reasons. One pretty recent example from our shop was that a third-party service change combined with some vague wording in one of our "start here" docs for new hires led to subtly broken development environments. More often, the changes just randomly make documentation somewhere between difficult-to-interpret and nonsensical. It also increases the cognitive load for less-frequent users. This has caused me to switch tools out of frustration. ("I'm already relearning this part of my workflow, may as well try something else and see if it sucks less...") And that's before we get to new bugs, locally-inopportune deprecations, broken integrations, forced on-the-fly workflow modifications and all the other negative externalities of change. The nicest way to avoid this is to not surprise people - let folks opt in to/roll out changes on their schedule. (With reasonable deadlines, of course, whatever that means in context.)