Right. Typically you’d sus out whether or not they’re qualified to speak about these things by listening to what they have to say instead of immediately implying they don’t know what they’re talking about asking them to confirm their qualifications, but maybe you just handle social dynamics differently.
Curious, since you’re comparing what you created to the play store, how many staff did you have working on your version, and how many years have you maintained it for?
And how many hundreds of millions of users were they handling, how many auxiliary services were provided in the SDK that they shared multiple platform, how many bad agents were trying to use their platform to infect millions of users, to run scams, etc., etc.
So you just don’t know what you’re talking about then.
Scaling up is by far the cause of the vast majority of the cost of developing truly massive systems, and the number of users you’re building for is unconditionally impossible to exclude from the math on anything that touches a server.
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.
So just to get this straight, you are arguing semantics, because you are excluding software development from research and development. I have no strong feelings about that, because I work exclusively in an r&d shop so everything I do is r&d, so I’ve lost sight of where the line is drawn. Seems silly though.
Additionally, you are citing your personal experience developing what you claim to be a similar system yet you haven’t shared details that can be used by others to confirm your experience is comparable to that of setting up and running the Google play store.
Is that right?
See the latter part is what suggests to everyone else that you’re not qualified to be contributing to this conversation. Share your experiences to convince folks you know what you’re talking about.
Or, I guess we can do things your way.
“Do you actually know anything about software engineering?”
See how much more productive one way is than the other?
Ongoing maintenance is literally part of system upkeep. You don’t include that in R&D costs. That’s akin to including power as a R&D cost.
Total staff involved in development? IIRC that wasn’t your original question, I believe you said something like “total users” or “total staff” in a way that could very easily be read as “how many people are involved today” which is a very different question.
Software development would obviously be included in the R&D cost, while total staff running the system after development would absolutely not be.
Why didn’t I provide information on the project? Because it would be so generalized due to NDA that it wouldn’t be useful. Here, let’s give it a go: The project in question was for a corporation with around half a million users. Serving internal applications to a large number of device types, though admittedly piggybacking on some external infrastructure since OS’s like iOS explicitly disallow self signing applications.
Admittedly, this pales in comparison to the PlayStore which is installed on billions of devices, though you won’t find many who have worked on something scaled that massive.
Did that explanation help? No of course not, because it provided so little information that it’s all but useless. It also doesn’t actually show that I know what I’m talking about. How was I involved? Was I a useful worker? How long was I part of the project?
Your question is just a long winded way of asking what I already did.
Ah, I was referring to maintenance as in the software development you need to do to maintain a competitive service for 15 years. Something like Google play wasn’t just “set it and forget it”, it’s continually been updated. That falls under r&d.
No, I just meant how many software engineers you had working under you. I’m barely transitioning from doing pure development to also being in charge of managing some projects, and the one thing I learned on this end is that engineers are expensive :)
That’s actually hugely helpful! It’s a wide customer base, and there are multiple device types. That’s pretty big! Folks now know that you at least have dealt with something in a similar vein as the Google play store. Are you allowed to say if it was spun up internally or vendor provided?
Even though you could have answered your own question with this, here’s what I believe the difference lies: did you feel like I was gatekeeping you when I asked for more details about your experience?
Right. Typically you’d sus out whether or not they’re qualified to speak about these things by listening to what they have to say instead of immediately
implying they don’t know what they’re talking aboutasking them to confirm their qualifications, but maybe you just handle social dynamics differently.Curious, since you’re comparing what you created to the play store, how many staff did you have working on your version, and how many years have you maintained it for?
And how many hundreds of millions of users were they handling, how many auxiliary services were provided in the SDK that they shared multiple platform, how many bad agents were trying to use their platform to infect millions of users, to run scams, etc., etc.
Like the individual you’re replying to, nothing you’re talking about falls into “research and development.”
Thanks for confirming you don’t know what you’re talking about. Take care.
So you just don’t know what you’re talking about then.
Scaling up is by far the cause of the vast majority of the cost of developing truly massive systems, and the number of users you’re building for is unconditionally impossible to exclude from the math on anything that touches a server.
Hey man I have a docker compose file that does everything so we Gucci. I’m basically Google.
Seriously, I could make a Facebook clone in a week.
Until it needs more than one user.
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.
Neither of those expenses fall into “research and development,” so would have no bearing on the discussion at hand.
So just to get this straight, you are arguing semantics, because you are excluding software development from research and development. I have no strong feelings about that, because I work exclusively in an r&d shop so everything I do is r&d, so I’ve lost sight of where the line is drawn. Seems silly though.
Additionally, you are citing your personal experience developing what you claim to be a similar system yet you haven’t shared details that can be used by others to confirm your experience is comparable to that of setting up and running the Google play store.
Is that right?
See the latter part is what suggests to everyone else that you’re not qualified to be contributing to this conversation. Share your experiences to convince folks you know what you’re talking about.
Or, I guess we can do things your way.
“Do you actually know anything about software engineering?”
See how much more productive one way is than the other?
Ongoing maintenance is literally part of system upkeep. You don’t include that in R&D costs. That’s akin to including power as a R&D cost.
Total staff involved in development? IIRC that wasn’t your original question, I believe you said something like “total users” or “total staff” in a way that could very easily be read as “how many people are involved today” which is a very different question.
Software development would obviously be included in the R&D cost, while total staff running the system after development would absolutely not be.
Why didn’t I provide information on the project? Because it would be so generalized due to NDA that it wouldn’t be useful. Here, let’s give it a go: The project in question was for a corporation with around half a million users. Serving internal applications to a large number of device types, though admittedly piggybacking on some external infrastructure since OS’s like iOS explicitly disallow self signing applications.
Admittedly, this pales in comparison to the PlayStore which is installed on billions of devices, though you won’t find many who have worked on something scaled that massive.
Did that explanation help? No of course not, because it provided so little information that it’s all but useless. It also doesn’t actually show that I know what I’m talking about. How was I involved? Was I a useful worker? How long was I part of the project?
Your question is just a long winded way of asking what I already did.
Ah, I was referring to maintenance as in the software development you need to do to maintain a competitive service for 15 years. Something like Google play wasn’t just “set it and forget it”, it’s continually been updated. That falls under r&d.
No, I just meant how many software engineers you had working under you. I’m barely transitioning from doing pure development to also being in charge of managing some projects, and the one thing I learned on this end is that engineers are expensive :)
That’s actually hugely helpful! It’s a wide customer base, and there are multiple device types. That’s pretty big! Folks now know that you at least have dealt with something in a similar vein as the Google play store. Are you allowed to say if it was spun up internally or vendor provided?
Even though you could have answered your own question with this, here’s what I believe the difference lies: did you feel like I was gatekeeping you when I asked for more details about your experience?