I enjoyed both write-ups, but I think there's a common misconception that resources are infinite because it's a big company.
"Notice the false dichotomy: “important” or not, as if only important bugs can or should be fixed. That’s a great way for smaller bugs to pile up and eventually become a mountain."
But... if every small bug is fixed, huge bugs can be introduced. Big teams writing software have many more hurdles to successfully release even a bugfix. Resources must be prioritized, and I'd rather a company be honest about the limitations than promise to fix every "thing" a developer finds that doesn't do exactly what they think it should.
In reality, what does a company do when they become so large that it would be a poor use of resources to have a developer respond and investigate every suggestion or small bug as if it was an important matter? How do the actually-important things get addressed?
I think the issue here is just a part of reality. You can encourage an environment like the Microsoft forums where you'll get a useless incoherent response to your post within minutes, the Google method where contacting them is a game unless you're somehow connecting with AdWords sales, or the Apple method where it's extremely easy to connect with a person by phone, in person, or electronically... but unimportant/non-priority requests aren't going to get any traction.
Personally, I'll always take the last option where contacting a human is not only possible, it is easily accomplished in a business day.
I have had excellent support from Apple when I have had pressing issues. But I also understand I'm a power user with an eye for QA - a rolling software release that met my high standards would be overkill for most people and be economically unfeasible for a even a gigantic for-profit company.
Suggesting big numbers like Google's quarterly revenue has any bearing on the organization's ability to address bugs in their myriad of releases tells me this can be boiled down as "man shakes fist at cloud" (pun intended)
This is a straw man that I never suggested. On the contrary, I said in Part 1, "I don’t fix every bug in my products."
> How do the actually-important things get addressed?
How exactly do you define "important"? And how do you address my point that the volume of so-called "unimportant" bugs can pile up until your product is noticeably full of those unimportant bugs?
> Suggesting big numbers like Google's quarterly revenue has any bearing on the organization's ability to address bugs in their myriad of releases tells me this can be boiled down as "man shakes fist at cloud" (pun intended)
Google is constantly, constantly, constantly, constantly adding new features. For example, they just introduced "AI Mode" in the Chrome omnibar. There's an infamously long list of products that Google created and then killed: https://killedbygoogle.com Google used to give their engineers 20% time to do whatever they wanted; I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff.
Google has vast engineering resources, more resources than almost any other company on Earth. They choose NOT to prioritize fixing bugs. Worse, they've obviously chosen to auto-close bugs that they've ignored, thereby incentivizing the ignoring of bugs, and deincentivizing the filing of bug reports.
> And how do you address my point that the volume of so-called "unimportant" bugs
I would address your point by first re-focusing our attention on the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand, so just grasping that again as part of the conversation seems to be necessary.
So, you asked about the "so-called" unimportant bugs? Yeah, they're called that because they're the unimportant ones. It sucks if an unimportant bug bothers you or interrupts your workflow - been there.
If unimportant bugs still seem important to you, an easy way to understand this concept is that in comparison, other bugs exist that are deemed even more important than these. And the company developing the software in question gets to make this call.
> a myriad of small, nearly-meaningless bugs ... pile up until your product is noticeably full of them.
I don't think that is at all how this works. There are numerous bugs and errors in software that have no real effect on users. Could they be fixed? Sure. But having 10 of these (your words) "nearly-meaningless" things still results in ... near-meaningless. If they had meaning and were important, people would be complaining so much about it that you couldn't sweep the issue away by auto-closing a dead 2-year-old ticket.
> Google is constantly, constantly, constantly, constantly adding new features.
Correct. It is what people/users seem to like and want. Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
> Worse, they've obviously chosen to auto-close bugs that they've ignored
They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. When that happens, important things don't get handled.
If the bugs being auto-closed were important, users would be clamoring about it, discussing the issue, and opening tickets with support. When one developer with a hawk-eye for errors drops a new bug/suggestion, it isn't going to get the same attention as a huge file-deletion bug in the new feature that just rolled out and is being actively used.
> I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff.
Again, even big companies do not have infinite resources. Just jumping to the conclusion that they're big means they should be able to do everything tells me there is a lack of experience speaking an opinion here.
I’ve seen that argument a few times, yet no one has ever been able to point to any tangible proof. Anecdotally, I see people significantly more frustrated by things working poorly than a lack of imagined features no one asked for.
> Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
They should first focus on the bugs to old features that the new features caused. Adding new functionality should never cause a regression to what already exists, but when it happens, those should be prioritised.
> the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand
This is nonsense. I don't agree at all. The meaning of "important" and "unimportant", with respect to any particular issue, is vague, controversial, arguable. It's ridiculous to suggest that we can easily put bugs into those two categories.
> There are numerous bugs and errors in software that have no real effect on users.
This is also nonsense. If there's "no real effect", then there's no bug.
> But having 10 of these (your words) "nearly-meaningless" things
What are you claiming to be my words?
> It is what people/users seem to like and want.
More accurately, what stockholders/advertisers seem to like and want.
> They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important.
That's nonsense, and not how it works. In fact the Google bug tracker has a specific "Priority" label for each report. You don't need to close a bug report to assign it a priority.
> When that happens, important things don't get handled.
That's not true either. Not all open bug reports get "handled".
> When one developer with a hawk-eye for errors drops a new bug/suggestion
1. I didn't drop a suggestion.
2. I didn't have a "hawk-eye for errors". I'm not specifically looking for bugs in Chrome. I have absolutely no desire to do free labor for an ultra-wealthy mega-corporation. I was simply using the developer tools, and they didn't work right.
> Just jumping to the conclusion that they're big means they should be able to do everything
Another straw man.
> there is a lack of experience speaking an opinion here
What "lack of experience" are you referring to? I've been a professional software developer for 19 years, how about you?
I enjoyed both write-ups, but I think there's a common misconception that resources are infinite because it's a big company.
"Notice the false dichotomy: “important” or not, as if only important bugs can or should be fixed. That’s a great way for smaller bugs to pile up and eventually become a mountain."
But... if every small bug is fixed, huge bugs can be introduced. Big teams writing software have many more hurdles to successfully release even a bugfix. Resources must be prioritized, and I'd rather a company be honest about the limitations than promise to fix every "thing" a developer finds that doesn't do exactly what they think it should.
In reality, what does a company do when they become so large that it would be a poor use of resources to have a developer respond and investigate every suggestion or small bug as if it was an important matter? How do the actually-important things get addressed?
I think the issue here is just a part of reality. You can encourage an environment like the Microsoft forums where you'll get a useless incoherent response to your post within minutes, the Google method where contacting them is a game unless you're somehow connecting with AdWords sales, or the Apple method where it's extremely easy to connect with a person by phone, in person, or electronically... but unimportant/non-priority requests aren't going to get any traction.
Personally, I'll always take the last option where contacting a human is not only possible, it is easily accomplished in a business day.
I have had excellent support from Apple when I have had pressing issues. But I also understand I'm a power user with an eye for QA - a rolling software release that met my high standards would be overkill for most people and be economically unfeasible for a even a gigantic for-profit company.
Suggesting big numbers like Google's quarterly revenue has any bearing on the organization's ability to address bugs in their myriad of releases tells me this can be boiled down as "man shakes fist at cloud" (pun intended)
> But... if every small bug is fixed
This is a straw man that I never suggested. On the contrary, I said in Part 1, "I don’t fix every bug in my products."
> How do the actually-important things get addressed?
How exactly do you define "important"? And how do you address my point that the volume of so-called "unimportant" bugs can pile up until your product is noticeably full of those unimportant bugs?
> Suggesting big numbers like Google's quarterly revenue has any bearing on the organization's ability to address bugs in their myriad of releases tells me this can be boiled down as "man shakes fist at cloud" (pun intended)
Google is constantly, constantly, constantly, constantly adding new features. For example, they just introduced "AI Mode" in the Chrome omnibar. There's an infamously long list of products that Google created and then killed: https://killedbygoogle.com Google used to give their engineers 20% time to do whatever they wanted; I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff.
Google has vast engineering resources, more resources than almost any other company on Earth. They choose NOT to prioritize fixing bugs. Worse, they've obviously chosen to auto-close bugs that they've ignored, thereby incentivizing the ignoring of bugs, and deincentivizing the filing of bug reports.
> And how do you address my point that the volume of so-called "unimportant" bugs
I would address your point by first re-focusing our attention on the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand, so just grasping that again as part of the conversation seems to be necessary.
So, you asked about the "so-called" unimportant bugs? Yeah, they're called that because they're the unimportant ones. It sucks if an unimportant bug bothers you or interrupts your workflow - been there.
If unimportant bugs still seem important to you, an easy way to understand this concept is that in comparison, other bugs exist that are deemed even more important than these. And the company developing the software in question gets to make this call.
> a myriad of small, nearly-meaningless bugs ... pile up until your product is noticeably full of them.
I don't think that is at all how this works. There are numerous bugs and errors in software that have no real effect on users. Could they be fixed? Sure. But having 10 of these (your words) "nearly-meaningless" things still results in ... near-meaningless. If they had meaning and were important, people would be complaining so much about it that you couldn't sweep the issue away by auto-closing a dead 2-year-old ticket.
> Google is constantly, constantly, constantly, constantly adding new features.
Correct. It is what people/users seem to like and want. Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
> Worse, they've obviously chosen to auto-close bugs that they've ignored
They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. When that happens, important things don't get handled.
If the bugs being auto-closed were important, users would be clamoring about it, discussing the issue, and opening tickets with support. When one developer with a hawk-eye for errors drops a new bug/suggestion, it isn't going to get the same attention as a huge file-deletion bug in the new feature that just rolled out and is being actively used.
> I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff.
Again, even big companies do not have infinite resources. Just jumping to the conclusion that they're big means they should be able to do everything tells me there is a lack of experience speaking an opinion here.
> It is what people/users seem to like and want.
I’ve seen that argument a few times, yet no one has ever been able to point to any tangible proof. Anecdotally, I see people significantly more frustrated by things working poorly than a lack of imagined features no one asked for.
> Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on?
They should first focus on the bugs to old features that the new features caused. Adding new functionality should never cause a regression to what already exists, but when it happens, those should be prioritised.
> the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand
This is nonsense. I don't agree at all. The meaning of "important" and "unimportant", with respect to any particular issue, is vague, controversial, arguable. It's ridiculous to suggest that we can easily put bugs into those two categories.
> There are numerous bugs and errors in software that have no real effect on users.
This is also nonsense. If there's "no real effect", then there's no bug.
> But having 10 of these (your words) "nearly-meaningless" things
What are you claiming to be my words?
> It is what people/users seem to like and want.
More accurately, what stockholders/advertisers seem to like and want.
> They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important.
That's nonsense, and not how it works. In fact the Google bug tracker has a specific "Priority" label for each report. You don't need to close a bug report to assign it a priority.
> When that happens, important things don't get handled.
That's not true either. Not all open bug reports get "handled".
> When one developer with a hawk-eye for errors drops a new bug/suggestion
1. I didn't drop a suggestion.
2. I didn't have a "hawk-eye for errors". I'm not specifically looking for bugs in Chrome. I have absolutely no desire to do free labor for an ultra-wealthy mega-corporation. I was simply using the developer tools, and they didn't work right.
> Just jumping to the conclusion that they're big means they should be able to do everything
Another straw man.
> there is a lack of experience speaking an opinion here
What "lack of experience" are you referring to? I've been a professional software developer for 19 years, how about you?