3 ms·

Disagree very, _very_ strongly on number 4. I love — love — weekly/biweekly/monthly release schedules with any software I use. As a user, it gives me the impre

Disagree very, _very_ strongly on number 4. I love — love — weekly/biweekly/monthly release schedules with any software I use. As a user, it gives me the impression that the software is being actively worked on, and to me that's very important. I don't care if the updates are minor, to the point of simply fixing typos. I like them, and want them frequently. I can also speak from the perspective of a developer. If you develop a new feature, why the hell would you wait for weeks/months to bundle it with other stuff, when you can release it whenever it's done and have your users start reaping its benefits right away? That way, they can also start giving you feedback much faster. This is why I love web browsers - honestly, every time a new Chrome/Firefox build is released, I update right away, and I read the release notes as well. In contrast, we use some enterprise software at work, and it comes out with a new version once a year, full of new features and bug fixes. I hate that. I hate that I have to wait for up to a year or more to get my hands on features I could have gained value from much sooner if the developers were on top of their game. I'm not saying you should release new features without testing and documenting them thoroughly. But the whole "bundling" approach is terribly wrong and misguided in my opinion.

_jal 7y ago
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.)
osamagirl69 7y ago
Sounds like you would be a prime candidate for a 'nightly' or 'developer preview' style release. Let the eager technically competent types give you feedback on the new features as you write them, provide feedback/bug reports etc, and when the new release is actually done push it out en masse.
sanitycheck 7y ago
I dread updates. If I'm using an app, it already does what I want. An update might introduce a bug, so I can't use the app anymore. An update might remove an important feature from the app, and force me to spend time and effort searching for an alternative (particularly annoying if I've paid for it). These sorts of things happen frustratingly often. For every app on every platform, I would like an LTS option which gets security fixes for a year with NO feature updates.

_jal 7y ago

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.)

osamagirl69 7y ago

Sounds like you would be a prime candidate for a 'nightly' or 'developer preview' style release. Let the eager technically competent types give you feedback on the new features as you write them, provide feedback/bug reports etc, and when the new release is actually done push it out en masse.

sanitycheck 7y ago

I dread updates. If I'm using an app, it already does what I want. An update might introduce a bug, so I can't use the app anymore. An update might remove an important feature from the app, and force me to spend time and effort searching for an alternative (particularly annoying if I've paid for it). These sorts of things happen frustratingly often. For every app on every platform, I would like an LTS option which gets security fixes for a year with NO feature updates.