• conciselyverbose@kbin.social
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    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.

    • papertowels
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Hey man I have a docker compose file that does everything so we Gucci. I’m basically Google.

    • KairuByte@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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?

      • conciselyverbose@kbin.social
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        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.

        • KairuByte@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          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.

      • falsem@kbin.social
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        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?

        https://android-developers.googleblog.com/2023/11/power-your-growth-on-google-play.html

        • KairuByte@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          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.