Scaling a well written system just requires throwing more hardware at said system. Yeah, you could tune it and tweak it, but that isn’t an ongoing and constant process.
Unless your argument is that they wrote it badly, and continuously improved it as more users were onboarded? Which is a ridiculous concept.
Again, none of this would be part of research and development. You aren’t still researching and developing… after the system is developed. Not unless you’re actually changing things. Can you tell me that last major feature added to the Play Store?
Scaling a well written system just requires throwing more hardware at said system. Yeah, you could tune it and tweak it, but that isn’t an ongoing and constant process.
Okay yeah, this conversation obviously isn’t going anywhere if you think the solution to scaling into hundreds of millions of users is just throwing hardware at the problem lol.
Can you tell me that last major feature added to the Play Store?
You can’t throw hardware at a scaling problem if the scaling problem is related to badly written code. Conversely, you can’t throw development at a scaling problem, if the problem is a hardware limitation.
If you take good code, which is already written to account for scaling, and it needs to be scaled up, what is it you think they do? Rewrite the code? Tweak the code over and over? No, they deploy a second server to employ load balancing.
Look at it this way, if more hardware is never the solution, you’re telling me I can run any code at any scale on my rPi4? Since that’s obviously not what you meant, it pretty easily proves that sometimes the answer is more hardware.
And fair enough on further development, I legitimately wasn’t aware. That said, I doubt that cost isn’t already rolled into the 30% cost referred to in the article. While the original user was arguing an unaccounted for $100 million “initial cost” that was still being “paid off.” I may have dug into that initial comment too much when making my statements.
There is no such thing as a magically built system that scales without continued work.
All the tools that make it remotely possible for smaller developers to scale to moderate (not big, let alone massive) scale are built by big companies like Google. You can’t just hand wave away the investment because some of it trickles down.
There will always be maintenance. That doesn’t even insinuate code writing. You don’t need to constantly rewrite the application as it scales up, that just insinuates bad code. And I highly doubt Google is paying their software developers as well as they are, only to get code that doesn’t scale.
As I said, a properly written application, which would inherently take scaling into account to be considered “properly written” would scale without constant need to rewrite code.
Ignoring that, do you think they are still rewriting parts of the application as maintenance? Going on 12 years and they are still tweaking the original code to support new users? Of course they aren’t, that’s insane.
Scaling a well written system just requires throwing more hardware at said system. Yeah, you could tune it and tweak it, but that isn’t an ongoing and constant process.
Unless your argument is that they wrote it badly, and continuously improved it as more users were onboarded? Which is a ridiculous concept.
Again, none of this would be part of research and development. You aren’t still researching and developing… after the system is developed. Not unless you’re actually changing things. Can you tell me that last major feature added to the Play Store?
Okay yeah, this conversation obviously isn’t going anywhere if you think the solution to scaling into hundreds of millions of users is just throwing hardware at the problem lol.
https://android-developers.googleblog.com/2023/11/power-your-growth-on-google-play.html
You can’t throw hardware at a scaling problem if the scaling problem is related to badly written code. Conversely, you can’t throw development at a scaling problem, if the problem is a hardware limitation.
If you take good code, which is already written to account for scaling, and it needs to be scaled up, what is it you think they do? Rewrite the code? Tweak the code over and over? No, they deploy a second server to employ load balancing.
Look at it this way, if more hardware is never the solution, you’re telling me I can run any code at any scale on my rPi4? Since that’s obviously not what you meant, it pretty easily proves that sometimes the answer is more hardware.
And fair enough on further development, I legitimately wasn’t aware. That said, I doubt that cost isn’t already rolled into the 30% cost referred to in the article. While the original user was arguing an unaccounted for $100 million “initial cost” that was still being “paid off.” I may have dug into that initial comment too much when making my statements.
There is no such thing as a magically built system that scales without continued work.
All the tools that make it remotely possible for smaller developers to scale to moderate (not big, let alone massive) scale are built by big companies like Google. You can’t just hand wave away the investment because some of it trickles down.
And yes, literally every line of code is R&D.
There will always be maintenance. That doesn’t even insinuate code writing. You don’t need to constantly rewrite the application as it scales up, that just insinuates bad code. And I highly doubt Google is paying their software developers as well as they are, only to get code that doesn’t scale.
As I said, a properly written application, which would inherently take scaling into account to be considered “properly written” would scale without constant need to rewrite code.
Ignoring that, do you think they are still rewriting parts of the application as maintenance? Going on 12 years and they are still tweaking the original code to support new users? Of course they aren’t, that’s insane.