3 ms·

How did they achieve monopoly if it weren't for the quality?

deleted 3y ago
[deleted]
lapcat 3y ago
The quality of what exactly? Google's massive internal processes and systems are the result of having already been huge for many years. Google needed the time and resources to build them up. They're not the cause of Google's becoming huge in the first place. Of course the quality of Google's external search results helped Google achieve a monopoly. Ironically, many people say that Google's search results have been getting worse, and I'd have to agree with that sentiment. See also the list of mergers and acquisitions by Alphabet: https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitions_by_Alphabet https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...
jacobr1 3y ago
I think you hit on a key part of the debate in this thread. There clearly is some sort of functional quality floor, in the sense that poor enough quality means something doesn't actually work to do its job. But beyond that, what is "quality"? Some would consider it to mean elegance of algorithmic and architectural design, or readability of code, or some other more abstract measure. Some consider it suitability to purpose, with low-bug count. I've give one example I observed commonly early in my career. The unexplained memory leak. Some process is running and the memory usage continues to grow. Eventually it will use the entire memory of its machine and die. You have a few options: 1) debug the issue and address the root cause 2) debug the issue and workaround it in some way 3) Give up and rewrite the code using some other kind of tooling 4) wake up people when the process dies and have them restart it 5) write a cron-job that restarts the process periodically. What is the right answer? The best from a QA perspective is probably to identify the root cause and fix the underlying issue. Tools like valgrind have made this much easier in recent years, but it still can be a challenge. Pragmatically, my own answer (speaking generally, there are more different cases for different contexts) would be to time-box and investigation and fix, and if that wasn't achievable in reasonable time, just write the cron-job and work on the next problem. You can imagine very successful operations filled with kludges like that. Is that low quality?

deleted 3y ago

[deleted]

The quality of what exactly? Google's massive internal processes and systems are the result of having already been huge for many years. Google needed the time and resources to build them up. They're not the cause of Google's becoming huge in the first place. Of course the quality of Google's external search results helped Google achieve a monopoly. Ironically, many people say that Google's search results have been getting worse, and I'd have to agree with that sentiment. See also the list of mergers and acquisitions by Alphabet: https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitions_by_Alphabet https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...

jacobr1 3y ago

I think you hit on a key part of the debate in this thread. There clearly is some sort of functional quality floor, in the sense that poor enough quality means something doesn't actually work to do its job. But beyond that, what is "quality"? Some would consider it to mean elegance of algorithmic and architectural design, or readability of code, or some other more abstract measure. Some consider it suitability to purpose, with low-bug count. I've give one example I observed commonly early in my career. The unexplained memory leak. Some process is running and the memory usage continues to grow. Eventually it will use the entire memory of its machine and die. You have a few options: 1) debug the issue and address the root cause 2) debug the issue and workaround it in some way 3) Give up and rewrite the code using some other kind of tooling 4) wake up people when the process dies and have them restart it 5) write a cron-job that restarts the process periodically. What is the right answer? The best from a QA perspective is probably to identify the root cause and fix the underlying issue. Tools like valgrind have made this much easier in recent years, but it still can be a challenge. Pragmatically, my own answer (speaking generally, there are more different cases for different contexts) would be to time-box and investigation and fix, and if that wasn't achievable in reasonable time, just write the cron-job and work on the next problem. You can imagine very successful operations filled with kludges like that. Is that low quality?