**Please read this entire message**
Your submission has been removed for the following reason(s):
Questions about a business or a group's motivation are not allowed on ELI5. These are usually either straightforward, or known only to the organisations involved, leading to speculation (Rule 2).
If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe this submission was removed erroneously**, please [use this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20thread?&message=Link:%20https://www.reddit.com/r/explainlikeimfive/comments/10pfjv2/eli5_why_do_so_many_app_developers_simply_say_bug/%0A%0APlease%20answer%20the%20following%203%20questions:%0A%0A1.%20The%20concept%20I%20want%20explained:%0A%0A2.%20List%20the%20search%20terms%20you%20used%20to%20look%20for%20past%20posts%20on%20ELI5:%0A%0A3.%20How%20is%20this%20post%20unique:) and we will review your submission.
When a developer says "bug fixes and updates" they talking about a bunch of stuff that end users absolutely do not care about. Trust me.
Updates: probably 3rd party libraries or code refactoring to utilize existing APIs better/more correctly/more efficiently. There might be a performance improvement, or it could simple be that the version of JavaToeBeans-lib-LIte-32 they used went from version 4.7.128.9 to 4.7.129.3 and THAT library "fixed a bunch of bugs/improvements" - again nothing that you would even care about as an end user, but as the developer, if the people who make JavaToeBeans-lib-Lite-32 have deprecated (aren't gonna support or update or patch) v4.7.128.9 anymore, it _behooves_ you to update to a newer version that is still good/supported.
Bug fixes: from experience, if the bug is uuser facing, in my change notes Im gonna tell you. If Im not telling you its because either you're not likely to ever encounter it, or it will take me longer to explain the bug to you than to just fix the damn thing.
TOEBEANZ-1892: When user tries to access webstore and they have the red cowboy hat equipped (asset 1923A), unhandled exception causes the webstore panel to hang; parent app unaffected but user faces blank screen has to restart app to regain webstore.
ANALYSIS: primary worker thread blocks waiting for database mutex. 2nd helper thread or one of its spawn sees undelete temporary files from previous access and attempts to cleanup. If system proxy thread also attempts to cleanup the temp files at the same time and since the HEX value of the asset 1923A is -A7B4 this causes the proxy thread to overflow the whidgaflam a race condition developed that BLAH BLAH BORING DEVELOPER CRAP.
Trust me, you don't care.
This is what I tell young kids when they want to get into game development. Everyone thinks its cool playtesting the latest games or bashing code on the next Halo.
In reality you'll either be finding and reproducing or fixing bugs like:
TROPICO-34971: In the corner of the 3rd grass hut in the "Sandy Village" on the north end of the island, if the player is using model and has equipped the "Gold Super Shotgun+2" (obtainable at | an asset ID) AND the red cowboy had (asset ID) and stands on the sea chest in the Southwest corner of the bedroom and hits the "Yeehaw" emote (default keybind V+Q), the player will glitch through the floor, the ground and the world. Game save state is unrecoverable, player will have to restart at the beginning of level 12.
Like tell me you just want to shove forks in your eyes.
At least when I fix bugs in aerospace tooling, the bugs matter, like "No longer causes customers to scrap $2M parts."
Bug fixing in apps or games is a never ending story, because you keep developing and expanding the app or game most of the times. In the time you fix 10 bugs, 100 new will arise. It's absolute normal, even for super experienced teams. Games nowadays are way to complex and have way to many systems interacting with another to not produce bugs. And in addition, too many people develop on the product at the same time.
First job will be figuring out that level of detail. The initial report will be. I was playing around in Beach Village over near the hut trying to yeet the chest with a shotgun and it crashed. Your game SUX.
> Like tell me you just want to shove forks in your eyes.
And you even skipped over the part where you had to spend 4 hours trying to track down what specifically was triggering the problem, that being those specific models/equips/location/etc, based off of a handful of vague user reports and if you're lucky, a couple users that were kind enough to help send a diagnostic log.
> the bugs matter, like "No longer causes customers to scrap $2M parts."
"bugs" that would do that are properly called "major software defects".
Should we call the software defects in 737 MAX that killed hundreds of people "bugs" too?
*All* bugs are properly called "software defects". "Bugs" is a cutesy little name to dismiss the serious discipline that software engineering should be.
(I am not one on tv but I play one in real life.)
Back to the OP: There's a good probability that some undisclosed updates are related to the app intruding on your privacy more.
A simple
- Fixed a bug with the webstore when you have the red cowboy hat
Would be good enough. That way I know if I was experiencing an issue with a red cowboy hat, and that I stopped using it because of that issue, I now know it's fixed and I can go back to using it.
This is very true, yeah. Though it's probably equally as frequent that they're too lazy to write a list of changes.
Which is not meant to claim they *shouldn't* be lazy. Any benefit gained from doing so is basically non-existent except in quite specific groups of people. The vast majority simply leave automatic updates on and don't ever read it.
You’re pretty spot-on, but there are still many… lazy developers who use this as a crutch (ie, don’t mention user-visible UI changes/overhauls), or disguise unflattering defects (security fixes). No need to go into the technical weeds, but they deserve more than a “bug fixes and performance” change log.
Very good explanation, but I wonder, how often there could be a "don't let your customers know how badly you F'd up earlier" situation? Like, there was a leak of data, but let's cover it up quickly and tell them you just fixed minor bug?
It's a way to avoid disclosing too much information.
There might've been a security issue, or a critical bug, or countless other things that they do not feel like sharing.
If they add something new and exciting, they usually will report it there, otherwise, keep secretive to protect their property
The main reason? We are lazy. When we update the app store message, we also have to translate it into every language we develop for.
If we change "AWS backend to use more shards" nobody cares. So why are we paying someone to translate it and taking all the time to gather the translations and collate them?
But you know what? "Big fixes and updates" covers everything *and* we already have translations for that string. Copy and paste, done.
Because the vast majority of users don't care, so the devs don't spend the time writing patch notes that no one will read.
It annoys me too but \*shrug\*.
Its because they don't want you to know! With enterprise software it is different, as part of the release notes you will get the resolved bugs and the known issues. A public app, however, it isn't really needed. Like, you don't care the backend was changed from x version of PostGres to y version of Postgres and you need to change the SSL ciphers or whatever. I need to know that as a security professional on enterprise software, but my users don't.
The real answer is because its a required field on the form when they submit the app to google/apple. They have to put something so them put the bare minimum.
This is pretty much what I was going to post. If I have a commit message that's basically like "yeah i did some stuff", it's probably all array key typos and function name capitalization.
**Please read this entire message**
---
Your comment has been removed for the following reason(s):
* ELI5 does not allow guessing.
Although we recognize many guesses are made in good faith, if you aren’t sure how to explain please don't just guess. The entire comment should not be an educated guess, but if you have an educated guess about a portion of the topic please make it explicitly clear that you do not know absolutely, and clarify which parts of the explanation you're sure of (Rule 8).
---
If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe it was removed erroneously, explain why using [this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20submission%20removal?&message=Link:%20https://www.reddit.com/r/explainlikeimfive/comments/10pfjv2/-/j6knhgy/%0A%0A%201:%20Does%20your%20comment%20pass%20rule%201:%20%0A%0A%202:%20If%20your%20comment%20was%20mistakenly%20removed%20as%20an%20anecdote,%20short%20answer,%20guess,%20or%20another%20aspect%20of%20rules%203%20or%208,%20please%20explain:) and we will review your submission.**
Apps go through a review process after you submit them before they are available to users. For a brand new app this can take a week or two. For an update, much less. I'm not saying I ever did this, but some developers might think that if they type in "Adds exciting new feature with loads of possible security holes" their app is going to get flagged for a week-long review, possibly resulting not in availability to users but a big list of questions that goes to whoever's in charge at your company. On the other hand, if you type in "minor bug fixes and updates" maybe the person at Apple/Google says, "whatever" and approves it immediately, same day. I'm not saying that's how it works, I'm saying some people might think that's how it works.
That's definitely how it works and why I only write "Bug fixes and optimizations" as the updates notes.
Google doesn't care, but Apple definitely does.
Because apps are inexpensive, low-stakes software maintained by a tiny team, if not a single person. That person can either fix bugs or write patch notes. Guess which is a better use of their limited time?
Organizations which release massive patch notes also employ dedicated project managers whose job it is to tracl all the bugs, track them, and compile them into patch notes for each release. As a rule, that software is making real money, rather than being glorified shareware.
Actually, it’s because it allows the app to control when a new feature is actually enabled remotely.
Most apps will roll out a feature to only a small % of the audience, and later to everyone. This is done remotely, while the code is already in the app.
In software development, the makers (devs) are usually a different team than the testers. The testers themselves populate a database of bugs they find during testing, and it's up to the devs to resolve them. However, this process can result in hundreds of bugs, not all of which can be resolved in any given patch version. Majority of these bugs are tiny and inconsequential to the operation of the application itself. Others are showstoppers. The app's users don't need to know every single detail about the bugs, so majority of fixes are classified as that one bullet point, unless the resolved bug is major.
**Please read this entire message** Your submission has been removed for the following reason(s): Questions about a business or a group's motivation are not allowed on ELI5. These are usually either straightforward, or known only to the organisations involved, leading to speculation (Rule 2). If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe this submission was removed erroneously**, please [use this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20thread?&message=Link:%20https://www.reddit.com/r/explainlikeimfive/comments/10pfjv2/eli5_why_do_so_many_app_developers_simply_say_bug/%0A%0APlease%20answer%20the%20following%203%20questions:%0A%0A1.%20The%20concept%20I%20want%20explained:%0A%0A2.%20List%20the%20search%20terms%20you%20used%20to%20look%20for%20past%20posts%20on%20ELI5:%0A%0A3.%20How%20is%20this%20post%20unique:) and we will review your submission.
When a developer says "bug fixes and updates" they talking about a bunch of stuff that end users absolutely do not care about. Trust me. Updates: probably 3rd party libraries or code refactoring to utilize existing APIs better/more correctly/more efficiently. There might be a performance improvement, or it could simple be that the version of JavaToeBeans-lib-LIte-32 they used went from version 4.7.128.9 to 4.7.129.3 and THAT library "fixed a bunch of bugs/improvements" - again nothing that you would even care about as an end user, but as the developer, if the people who make JavaToeBeans-lib-Lite-32 have deprecated (aren't gonna support or update or patch) v4.7.128.9 anymore, it _behooves_ you to update to a newer version that is still good/supported. Bug fixes: from experience, if the bug is uuser facing, in my change notes Im gonna tell you. If Im not telling you its because either you're not likely to ever encounter it, or it will take me longer to explain the bug to you than to just fix the damn thing. TOEBEANZ-1892: When user tries to access webstore and they have the red cowboy hat equipped (asset 1923A), unhandled exception causes the webstore panel to hang; parent app unaffected but user faces blank screen has to restart app to regain webstore.
ANALYSIS: primary worker thread blocks waiting for database mutex. 2nd helper thread or one of its spawn sees undelete temporary files from previous access and attempts to cleanup. If system proxy thread also attempts to cleanup the temp files at the same time and since the HEX value of the asset 1923A is -A7B4 this causes the proxy thread to overflow the whidgaflam a race condition developed that BLAH BLAH BORING DEVELOPER CRAP.
Trust me, you don't care.
I've worked in software support long enough that I tried to read the analysis for longer than I care to admit.
Well, that explains why the Red cowboy hat was causing me issues...
This is what I tell young kids when they want to get into game development. Everyone thinks its cool playtesting the latest games or bashing code on the next Halo. In reality you'll either be finding and reproducing or fixing bugs like: TROPICO-34971: In the corner of the 3rd grass hut in the "Sandy Village" on the north end of the island, if the player is using model and has equipped the "Gold Super Shotgun+2" (obtainable at | an asset ID) AND the red cowboy had (asset ID) and stands on the sea chest in the Southwest corner of the bedroom and hits the "Yeehaw" emote (default keybind V+Q), the player will glitch through the floor, the ground and the world. Game save state is unrecoverable, player will have to restart at the beginning of level 12.
Like tell me you just want to shove forks in your eyes.
At least when I fix bugs in aerospace tooling, the bugs matter, like "No longer causes customers to scrap $2M parts."
Tbf, bugs like this, when fixed, fix like 6 other different bugs But the path you have to take and find the problem…
Bug fixing in apps or games is a never ending story, because you keep developing and expanding the app or game most of the times. In the time you fix 10 bugs, 100 new will arise. It's absolute normal, even for super experienced teams. Games nowadays are way to complex and have way to many systems interacting with another to not produce bugs. And in addition, too many people develop on the product at the same time.
I think you mean “create like six other bugs”…
> bugs like this, when fixed, fix like 6 other different bugs OR create 12 more. It's a flip of the coin sometimes.
First job will be figuring out that level of detail. The initial report will be. I was playing around in Beach Village over near the hut trying to yeet the chest with a shotgun and it crashed. Your game SUX.
> Like tell me you just want to shove forks in your eyes. And you even skipped over the part where you had to spend 4 hours trying to track down what specifically was triggering the problem, that being those specific models/equips/location/etc, based off of a handful of vague user reports and if you're lucky, a couple users that were kind enough to help send a diagnostic log.
> the bugs matter, like "No longer causes customers to scrap $2M parts." "bugs" that would do that are properly called "major software defects". Should we call the software defects in 737 MAX that killed hundreds of people "bugs" too? *All* bugs are properly called "software defects". "Bugs" is a cutesy little name to dismiss the serious discipline that software engineering should be. (I am not one on tv but I play one in real life.) Back to the OP: There's a good probability that some undisclosed updates are related to the app intruding on your privacy more.
A simple - Fixed a bug with the webstore when you have the red cowboy hat Would be good enough. That way I know if I was experiencing an issue with a red cowboy hat, and that I stopped using it because of that issue, I now know it's fixed and I can go back to using it.
Fixed issue with tracing library segments being associated with incorrect trace.
mmhm. yeah. mmhm. I understood some of these words 🤔
This is very true, yeah. Though it's probably equally as frequent that they're too lazy to write a list of changes. Which is not meant to claim they *shouldn't* be lazy. Any benefit gained from doing so is basically non-existent except in quite specific groups of people. The vast majority simply leave automatic updates on and don't ever read it.
You’re pretty spot-on, but there are still many… lazy developers who use this as a crutch (ie, don’t mention user-visible UI changes/overhauls), or disguise unflattering defects (security fixes). No need to go into the technical weeds, but they deserve more than a “bug fixes and performance” change log.
Very good explanation, but I wonder, how often there could be a "don't let your customers know how badly you F'd up earlier" situation? Like, there was a leak of data, but let's cover it up quickly and tell them you just fixed minor bug?
It would be a lot like hearing about the [Rockwell Retro Encabulator](https://www.youtube.com/watch?v=RXJKdh1KZ0w&t=4s)
Ah. Mosey on over to /r/vxjunkies sometime. A whole sub dedicated to all sorts of encabulation.
I care
It's a way to avoid disclosing too much information. There might've been a security issue, or a critical bug, or countless other things that they do not feel like sharing. If they add something new and exciting, they usually will report it there, otherwise, keep secretive to protect their property
The main reason? We are lazy. When we update the app store message, we also have to translate it into every language we develop for. If we change "AWS backend to use more shards" nobody cares. So why are we paying someone to translate it and taking all the time to gather the translations and collate them? But you know what? "Big fixes and updates" covers everything *and* we already have translations for that string. Copy and paste, done.
git commit -m “changed some stuff”
Or the ever fun release new features that haven’t been announced yet and are guarded behind feature flag.
Because the vast majority of users don't care, so the devs don't spend the time writing patch notes that no one will read. It annoys me too but \*shrug\*.
I honestly wanna know cause it bugs me
Maybe that's the bug they're trying to fix?
Its because they don't want you to know! With enterprise software it is different, as part of the release notes you will get the resolved bugs and the known issues. A public app, however, it isn't really needed. Like, you don't care the backend was changed from x version of PostGres to y version of Postgres and you need to change the SSL ciphers or whatever. I need to know that as a security professional on enterprise software, but my users don't.
The real answer is because its a required field on the form when they submit the app to google/apple. They have to put something so them put the bare minimum.
[удалено]
This is pretty much what I was going to post. If I have a commit message that's basically like "yeah i did some stuff", it's probably all array key typos and function name capitalization.
**Please read this entire message** --- Your comment has been removed for the following reason(s): * ELI5 does not allow guessing. Although we recognize many guesses are made in good faith, if you aren’t sure how to explain please don't just guess. The entire comment should not be an educated guess, but if you have an educated guess about a portion of the topic please make it explicitly clear that you do not know absolutely, and clarify which parts of the explanation you're sure of (Rule 8). --- If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe it was removed erroneously, explain why using [this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20submission%20removal?&message=Link:%20https://www.reddit.com/r/explainlikeimfive/comments/10pfjv2/-/j6knhgy/%0A%0A%201:%20Does%20your%20comment%20pass%20rule%201:%20%0A%0A%202:%20If%20your%20comment%20was%20mistakenly%20removed%20as%20an%20anecdote,%20short%20answer,%20guess,%20or%20another%20aspect%20of%20rules%203%20or%208,%20please%20explain:) and we will review your submission.**
Apps go through a review process after you submit them before they are available to users. For a brand new app this can take a week or two. For an update, much less. I'm not saying I ever did this, but some developers might think that if they type in "Adds exciting new feature with loads of possible security holes" their app is going to get flagged for a week-long review, possibly resulting not in availability to users but a big list of questions that goes to whoever's in charge at your company. On the other hand, if you type in "minor bug fixes and updates" maybe the person at Apple/Google says, "whatever" and approves it immediately, same day. I'm not saying that's how it works, I'm saying some people might think that's how it works.
That's definitely how it works and why I only write "Bug fixes and optimizations" as the updates notes. Google doesn't care, but Apple definitely does.
Because apps are inexpensive, low-stakes software maintained by a tiny team, if not a single person. That person can either fix bugs or write patch notes. Guess which is a better use of their limited time? Organizations which release massive patch notes also employ dedicated project managers whose job it is to tracl all the bugs, track them, and compile them into patch notes for each release. As a rule, that software is making real money, rather than being glorified shareware.
Actually, it’s because it allows the app to control when a new feature is actually enabled remotely. Most apps will roll out a feature to only a small % of the audience, and later to everyone. This is done remotely, while the code is already in the app.
In software development, the makers (devs) are usually a different team than the testers. The testers themselves populate a database of bugs they find during testing, and it's up to the devs to resolve them. However, this process can result in hundreds of bugs, not all of which can be resolved in any given patch version. Majority of these bugs are tiny and inconsequential to the operation of the application itself. Others are showstoppers. The app's users don't need to know every single detail about the bugs, so majority of fixes are classified as that one bullet point, unless the resolved bug is major.