12 ms·
The reason these bigger apps just put "Bugfixes" and "Performance Improvements" in their changelog is because when you have many teams contributing to the softw
by mfDjB 6y ago
The reason these bigger apps just put "Bugfixes" and "Performance Improvements" in their changelog is because when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in. Doubly so when different users are receiving different experiences.
The article says at the end: "You see? Not that hard right?". It is that hard in bigger organisations.
- temac 6y agoIt is bugfixes or performance improvements about things that exist, though.
- coldtea 6y ago>The article says at the end: "You see? Not that hard right?". It is that hard in bigger organisations. The size of the organisations is not important, as is the size of the team working on the particular feature/app. Apple is huge, for example, but eg. Logic Pro has great changelogs. We also see huge apps (with large teams) do better than than small apps (with much smaller teams). It's more about bothering/caring than difficulty.
- mackey 6y agoApple has a much more traditional engineering structure and traditional release cadence though. A lot of the "worst offenders" of these types of release notes are structured and work much differently. They release updates 1-2 times a week, sometimes release features weeks after the code has shipped to users, and sometimes in stretched out rollouts. They say there if there is a will, there is a way, so in a sense I agree that these companies probably could do something about it if they really wanted to, but I also don't think it would be easy, and considering how few people actually look at release notes, I am not sure the investment is worth it.
- damnyou 6y agoLogic Pro doesn't have server-side feature flags.
- hashkb 6y agoDifficulty of task never excuses doing a lazy job. Especially if you hope people will pay you.
- fwip 6y agoIf it's worth doing, it's worth doing half-assed.
- joepie91_ 6y ago> when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in. This is a terrifying sentence to me, because what it implies but doesn't say outright, is that there's not a single person in the organization who actually fully knows what is being released. If there were, then they should already have this information! Honestly, if you don't have a release manager with a 30,000 foot view of the operation, you probably have bigger organizational problems than "it's hard to know what to fill in on the app store's release notes". This is how retrospectives on supply chain attacks start, basically.
- JimDabell 6y ago> This is a terrifying sentence to me, because what it implies but doesn't say outright, is that there's not a single person in the organization who actually fully knows what is being released. If there were, then they should already have this information! It’s not the collection of the information that’s difficult, it’s delivering it to the user in an appropriate way when you use phased rollouts with feature flags. The change log that the App Store presents to the user is static and identical for everybody. The changes that a user actually experiences are not. So you might have 0% of your users experiencing a certain feature when the release goes out, 10% a day later, 50% a day after that, and 100% at the end of the week. Or, if the metrics show a bad response, it might end up at maximum 10% seeing it, and then it dropping back down to 0% the next day. Apple gives you a static text field to enter the change log information, with limited length. If you have ten different features to release, your users will all receive them at different times, and not all of them are guaranteed to make it out to everybody, how is a static text field supposed to deliver that information?
- Master_Odin 6y ago"Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>." If you don't put anything about new features, don't be surprised when users don't use them (because why would they know) or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.
- 0xbadcafebee 6y agoWhich is a good indication that the organization actually has no idea what the heck is going into the update.
- damnyou 6y agoAssuming there are good rollout and incident review processes in place, this isn't much of a problem in practice.
- toast0 6y agoIf you're shipping a mobile app with client side code (so, nearly all of them), there is no good rollout process. You can't ship a quick update with Apple, because review isn't quick. Users who upgraded soon after release will be stuck with something broken until the new version is available. You can usually ship quickly with Google, but users are slow to upgrade, but may have caught your first one, and not get your second one for some time.
- damnyou 6y agoI'm talking about feature flag based rollouts, which don't involve going through Apple or Google.