Why reporting bugs to Apple may harm software quality(eclecticlight.co)
eclecticlight.co
Why reporting bugs to Apple may harm software quality
https://eclecticlight.co/2021/02/16/why-reporting-bugs-to-apple-may-harm-software-quality/
13 comments
There are 62 comments there. E.g. here's a snippet:
Just why should Apple care any longer? They already are raking in money faster than it can be printed. They get rave press reviews. They have large enough market share that would be hard to improve upon. And, the big one – what are the alternatives for consumers?
To reiterate: Why should Apple care?
Just why should Apple care any longer? They already are raking in money faster than it can be printed. They get rave press reviews. They have large enough market share that would be hard to improve upon. And, the big one – what are the alternatives for consumers?
To reiterate: Why should Apple care?
Pretty much this. Especially true when Microsoft or Google aren't even trying to compete.
This is a great example of systems thinking. You may see some starving birds outside so you go feed them. But as people do that, the population of birds merely increases up to the malthusian point so that larger population is again on the verge of starvation. By feeding some birds you merely replaced one hungry bird with two hungry birds.
Systems thinking is about trying to understand the new stable equilibrium that will result in response to an intervention, rather than thinking about the local, immediate response to a given action (you feel good for feeding the bird. The bird feels good. What can be wrong with that?).
Once you realize that, the whole world changes. All of a sudden very obvious and simple prescriptions come into doubt.
Am I really helping make an OS better by reporting bugs? Maybe not. And not just an OS, but business models in general, economic development, poverty, education, family formation, trade, legal systems -- many questions that before had very simple, moral answers that were "obviously" right are now filled with questions and doubt. Are the long term results really what I expect?
And with this new doubt comes a realization that it's hard to tell what the effects of an intervention will be until you have a pretty deep understanding of the system you are describing as well as its future evolution in a wide variety of scenarios. This itself requires a deep understanding of human nature. As these are all in doubt, opposing views stop being people on the "wrong side" but people who have different predictions about core aspects of human nature which themselves are up to debate.
This is why I suspect the post was written by an old timer. Young, enthusiastic engineers just don't think in terms of systems, they tend to think in simple terms of stimulus/response, or right/wrong, help/hurt. This isn't due to a lack of intelligence, or poor intellectual curiosity. But simply because unlike the help/hurt localized stuff, a deep understanding of the long term behavior of a system can only come from living in that system, observing it respond to stimulus, and carefully observing how past interventions worked out. Over and over, over many years. Gaining that perspective is measured in decades, not years, of careful observation.
And after those decades, you will be painfully aware of how incomplete and faulty your understanding actually is. You become much more cautious, much more skeptical, and question a lot of obvious assumptions. Hopefully this additional perspective doesn't make you more gloomy or cranky, but it certainly seems that way to the enthusiastic new entrant, for whom it's obviously the case that when the public reports more bugs, this can only improve code quality and at worst will leave code quality unchanged.
Systems thinking is about trying to understand the new stable equilibrium that will result in response to an intervention, rather than thinking about the local, immediate response to a given action (you feel good for feeding the bird. The bird feels good. What can be wrong with that?).
Once you realize that, the whole world changes. All of a sudden very obvious and simple prescriptions come into doubt.
Am I really helping make an OS better by reporting bugs? Maybe not. And not just an OS, but business models in general, economic development, poverty, education, family formation, trade, legal systems -- many questions that before had very simple, moral answers that were "obviously" right are now filled with questions and doubt. Are the long term results really what I expect?
And with this new doubt comes a realization that it's hard to tell what the effects of an intervention will be until you have a pretty deep understanding of the system you are describing as well as its future evolution in a wide variety of scenarios. This itself requires a deep understanding of human nature. As these are all in doubt, opposing views stop being people on the "wrong side" but people who have different predictions about core aspects of human nature which themselves are up to debate.
This is why I suspect the post was written by an old timer. Young, enthusiastic engineers just don't think in terms of systems, they tend to think in simple terms of stimulus/response, or right/wrong, help/hurt. This isn't due to a lack of intelligence, or poor intellectual curiosity. But simply because unlike the help/hurt localized stuff, a deep understanding of the long term behavior of a system can only come from living in that system, observing it respond to stimulus, and carefully observing how past interventions worked out. Over and over, over many years. Gaining that perspective is measured in decades, not years, of careful observation.
And after those decades, you will be painfully aware of how incomplete and faulty your understanding actually is. You become much more cautious, much more skeptical, and question a lot of obvious assumptions. Hopefully this additional perspective doesn't make you more gloomy or cranky, but it certainly seems that way to the enthusiastic new entrant, for whom it's obviously the case that when the public reports more bugs, this can only improve code quality and at worst will leave code quality unchanged.
Interesting. Do you have any good resources (books etc) to learn how to think in systems?
Most famous general book would be Gall's Systematics
https://en.wikipedia.org/wiki/John_Gall_(author)
He is the author of the famous Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system
But then you need to dive into the field you are asking questions about. So, for example, you'd need some knowledge about how software engineering organizations work to help answer the OS/bug question. Gall's law just takes a critical look at systems and tries to describe common patterns of human organization. It has a lot of insight. "The Mythical Man Month" is great for insights on software engineering. Other books have good insights on corporate culture, business, etc.
Also Taleb, although I find him opinionated and annoying, does have useful insights on risk that are important to understand.
He is the author of the famous Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system
But then you need to dive into the field you are asking questions about. So, for example, you'd need some knowledge about how software engineering organizations work to help answer the OS/bug question. Gall's law just takes a critical look at systems and tries to describe common patterns of human organization. It has a lot of insight. "The Mythical Man Month" is great for insights on software engineering. Other books have good insights on corporate culture, business, etc.
Also Taleb, although I find him opinionated and annoying, does have useful insights on risk that are important to understand.
Donella Meadows, _Thinking in Systems_.
John Gall's _Systemantics_ is a classic, but it's a bit cranky.
Related:
John Boardman, _Systems Thinking_.
Gerald Weinberg, _An Introduction to General Systems Thinking_
John Sterman, _Business Dynamics_.
John Gall's _Systemantics_ is a classic, but it's a bit cranky.
Related:
John Boardman, _Systems Thinking_.
Gerald Weinberg, _An Introduction to General Systems Thinking_
John Sterman, _Business Dynamics_.
Indeed system thinking is useful but you seem to be missing that no prediction js ever accurate, nor can any system model fully cover the real complexity. System thinking is a tool, not the ultimate truth, and your system model will always be imperfect.
Even if your model was perfect, you should not simply assume that a theoretical future really holds moral weight beyond that of the actual present. Feeding a duck today means two hungry ducks next year. Possible. Feeding a hungry human today means two hungry humans next year. Possible. But are you going to let a human (or a duck for that matter) starve to death to avoid theoretical future suffering, especially when the outcome is not guaranteed? What if the one you saved is a unique duck whose genes will make all offspring resistant to a certain pathogen? What if the human will be an important contributor to mankind's future? Or what if this human won't have children? Or what if they will be fed two days later by someone else regardless, which means your choice not to feed them only prolonged their suffering with no change in long-term outcome?
Brought ad absurdum: the only moral choice is nuclear war - kill us all now to reduce future suffering of our children, grandchildren, etc.
System thinking is useful, but don't think it has magical powers. Applied it helps you to see a broader horizon but it is always as flawed as your assumptions and model.
Even if your model was perfect, you should not simply assume that a theoretical future really holds moral weight beyond that of the actual present. Feeding a duck today means two hungry ducks next year. Possible. Feeding a hungry human today means two hungry humans next year. Possible. But are you going to let a human (or a duck for that matter) starve to death to avoid theoretical future suffering, especially when the outcome is not guaranteed? What if the one you saved is a unique duck whose genes will make all offspring resistant to a certain pathogen? What if the human will be an important contributor to mankind's future? Or what if this human won't have children? Or what if they will be fed two days later by someone else regardless, which means your choice not to feed them only prolonged their suffering with no change in long-term outcome?
Brought ad absurdum: the only moral choice is nuclear war - kill us all now to reduce future suffering of our children, grandchildren, etc.
System thinking is useful, but don't think it has magical powers. Applied it helps you to see a broader horizon but it is always as flawed as your assumptions and model.
Really annoying but contrast the Microsoft approach, where you basically can’t report issues at all.
I don’t know which one is worse.
I don’t know which one is worse.
Maybe at certain scale it starts to be impossible to digest bug reports from consumers. False reports, lack of details etc.
People who are in the business know it takes a lot of effort to dig enough information from users. Through email this is even harder - people respond slowly so you loose context. Many abandon the whole process midway. Bunch of people just expect this to be a generic support and get angry.
If you are not going to dig into the reports, then it might be more polite to not ask them in first place.
People who are in the business know it takes a lot of effort to dig enough information from users. Through email this is even harder - people respond slowly so you loose context. Many abandon the whole process midway. Bunch of people just expect this to be a generic support and get angry.
If you are not going to dig into the reports, then it might be more polite to not ask them in first place.
As far as I know Microsoft simply thinks users don’t have issues to report that are worth mentioning. After all, 90% of issues are in third party code. And Microsoft thinks they detect a large part of the rest through their telemetry.
My thinking was that if you are getting QA for free, you should be falling all over yourself to make it easy for it to happen.
In other terms, the user interface for bug reporting should be EVEN MORE streamlined than a sign-up process or a shopping cart checkout process.
But put in the terms of this article, maybe it should continue to be fiddly and cumbersome for the sake of the software.