• dandi8@fedia.io
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    I have never, in my decade as a software dev, seen a role dedicated to “making sure unit tests stay functional, meet standards and fixing them”. That is the developer’s job, and the job of the code review.

    The tests must be up to standards and functional before the functionality they’re testing gets merged into main. Otherwise, yes, you may actually need hundreds of engineers just to keep your application somewhat functional.

    Finally, 30 engineers can be a vast breadth of knowledge.

    • RubberDuck@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      So cool that you got to work with teams of devs that where able to do that. Was it for software used in a OT environment? Cause stuff like telegram seems a lot more like that imho.

      And the bredth… 30 people can cover it all, yes. Doing that in a 24/7 global environment means 3 of several competences, in shifts, covering timezones. It’s not as if you can just click out at 5 and come back tomorrow.

      • dandi8@fedia.io
        link
        fedilink
        arrow-up
        0
        ·
        3 months ago

        I have no idea why you’re even bringing up OT. We’re not talking about PLCs or scientific equipment here, we’re talking about glorified web apps.

        Web apps that need to be secure and highly available, for sure, but web apps all the same.

        • RubberDuck@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 months ago

          A point of pride sure, also a risk. Responding to incidents requires coverage. And the OT comparison was just more on the uptime requirements and redundancies than anything else.

          • dandi8@fedia.io
            link
            fedilink
            arrow-up
            0
            ·
            3 months ago

            It’s no more a risk than throwing more developers at it when they’re not needed.

            “Too many devs“ can, and often is, a significant bottleneck in and of itself. The codebase may simply not be big enough to fit more.

            Besides, I still don’t see what all those additional engineers would actually be doing. “Responding to incidents” presupposes a large number of incidents. In other words, the assumption is that the application will be buggy, or insecure enough, that 30 engineers will not be enough to apply the duct tape. I stand by the claim that an application adhering to modern standards and practices will not have as many bugs or security breaches, and therefore 30 engineers sounds like a completely reasonable amount.