> Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done.
One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development.
A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!".
I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read:
* List every change or commit message, especially without categorizing or simplifying the wording
* Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document
Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable).
One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development.
A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!".
I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read:
* List every change or commit message, especially without categorizing or simplifying the wording
* Don't properly highlight feature changes (eg with screenshots and/or reasoning)
* Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document
Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable).
[1] https://code.visualstudio.com/updates/v1_52
[2] https://confluence.atlassian.com/jirasoftware/jira-software-...
[3] https://about.gitlab.com/releases/categories/releases/
[4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...