9 ms·

There are pros and cons of having dedicated teams for work that also has to be accomplished by other teams. For instance, it's not a good idea to skip having a

There are pros and cons of having dedicated teams for work that also has to be accomplished by other teams. For instance, it's not a good idea to skip having a security team using the logic that "other teams will just think its that one teams job." The security team provides expertise and (with cooperative management or other teams) can enact policies that influence the rest of the organization to the benefit of security. That can't happen without a set of people dedicated to thinking about those problems. For your QA team example, the mistake made in some organizations is explicitly removing testing from developer's responsibilities. It's a matter of BOTH/AND -- you need to have BOTH central teams responsible for long term health of {safety,privacy,security,testing,etc.} AND hold developers responsible to deliver the recommendations of and use the tools developed by central teams.

mcguire 6y ago
Aww, c'mon, tell me that QA/security/accessibility/whatever isn't regarded as a meaningless hoop to be jumped through as quickly and with the least effort possible so that you can get real work done. Ain't nobody got time for that rigamarole.
- loopz 6y ago
  With EU laws, GDPR and UX fanatics, many have to do the heavy lifting or risk multimillion dollar fines. So it's changing.
- georgeecollins 6y ago
  In games, QA is taken very seriously. I know with games like Cybepunk people think game developers don't care about QA, but I am sure that is a certain circumstance where they chose to ignore problems. On big games you count on QA for feedback.
  - deleted 6y ago
    [deleted]
- vorpalhex 6y ago
  If you're shipping buggy and insecure software, you will soon get a whole lot of free time on your hands.
  - chii 6y ago
    That's why i think devops has some good ideas - you are responsible for the shit you ship. Also developer on calls - if you ship shit that goes down or causes errors, you get woken up in the middle of the night or during your vacation.
    - pertymcpert 6y ago
      I disagree about on call developers. No one should have to be half at work on their time off. Fix the business model so that becomes unnecessary.
      - chii 6y ago
        there is no model where that becomes unnecessary. If someone who did not create the product is on call, they become the poor sod stuck solving a problem of not their own making. > half at work on their time off i mean not constantly. Also if you're on call, you're always paid for doing so regardless of what happens. This talk isn't about compensation, but about the model of work.
        pertymcpert 6y ago
        There is. You split the team or hire additional engineers in other time zones, such that no one is relied upon to work on their time off. There should always be someone working at all times around the globe, available to support.
      - vorpalhex 6y ago
        I was part of a group that inherited a really buggy service platform, maybe a dozen services, 3 generations of most services still around, no logging, nothing. The previous team had kept some foreign engineers on-call and never taken shifts - and there were daily pages, absurd processes to "fix" things, etc. In about two weeks of putting engineers on call for their own services, most of the major problems were fixed. It's easy to write buggy software when you aren't the one who gets called at 2am to fix it. Once you start being responsible for your software, the urge to take shortcuts really evaporates. On the other hand, a team that is not responsible for their output will always cut corners - it's just the way it goes.
- esc_colon_q 6y ago
  If you make these things Big Process, each of which requires spreadsheets and certification by high level manager and weeks of delay, etc, then yes, people will think of them as meaningless hoops. If you can avoid dumb red tape then things can go quite well. In games, when QA reports into the same person managing the product, things run smoothly and everyone remains aligned towards shipping a good product. When it's a separate org that loans people out and has OKRs that don't connect to individual products, they become horrible trolls who are only out to fuck the product up by submitting so many bug reports that it can never be released. Sim with whole-company legal teams ("never ship anything, we might get sued") and shared security ("never run services or we might get hacked") and ops ("never use servers or they might crash"). Alignment is everything.

mcguire 6y ago

Aww, c'mon, tell me that QA/security/accessibility/whatever isn't regarded as a meaningless hoop to be jumped through as quickly and with the least effort possible so that you can get real work done. Ain't nobody got time for that rigamarole.

loopz 6y ago
With EU laws, GDPR and UX fanatics, many have to do the heavy lifting or risk multimillion dollar fines. So it's changing.
georgeecollins 6y ago
In games, QA is taken very seriously. I know with games like Cybepunk people think game developers don't care about QA, but I am sure that is a certain circumstance where they chose to ignore problems. On big games you count on QA for feedback.
- deleted 6y ago
  [deleted]
vorpalhex 6y ago
If you're shipping buggy and insecure software, you will soon get a whole lot of free time on your hands.
- chii 6y ago
  That's why i think devops has some good ideas - you are responsible for the shit you ship. Also developer on calls - if you ship shit that goes down or causes errors, you get woken up in the middle of the night or during your vacation.
  - pertymcpert 6y ago
    I disagree about on call developers. No one should have to be half at work on their time off. Fix the business model so that becomes unnecessary.
    - chii 6y ago
      there is no model where that becomes unnecessary. If someone who did not create the product is on call, they become the poor sod stuck solving a problem of not their own making. > half at work on their time off i mean not constantly. Also if you're on call, you're always paid for doing so regardless of what happens. This talk isn't about compensation, but about the model of work.
      - pertymcpert 6y ago
        There is. You split the team or hire additional engineers in other time zones, such that no one is relied upon to work on their time off. There should always be someone working at all times around the globe, available to support.
    - vorpalhex 6y ago
      I was part of a group that inherited a really buggy service platform, maybe a dozen services, 3 generations of most services still around, no logging, nothing. The previous team had kept some foreign engineers on-call and never taken shifts - and there were daily pages, absurd processes to "fix" things, etc. In about two weeks of putting engineers on call for their own services, most of the major problems were fixed. It's easy to write buggy software when you aren't the one who gets called at 2am to fix it. Once you start being responsible for your software, the urge to take shortcuts really evaporates. On the other hand, a team that is not responsible for their output will always cut corners - it's just the way it goes.
esc_colon_q 6y ago
If you make these things Big Process, each of which requires spreadsheets and certification by high level manager and weeks of delay, etc, then yes, people will think of them as meaningless hoops. If you can avoid dumb red tape then things can go quite well. In games, when QA reports into the same person managing the product, things run smoothly and everyone remains aligned towards shipping a good product. When it's a separate org that loans people out and has OKRs that don't connect to individual products, they become horrible trolls who are only out to fuck the product up by submitting so many bug reports that it can never be released. Sim with whole-company legal teams ("never ship anything, we might get sued") and shared security ("never run services or we might get hacked") and ops ("never use servers or they might crash"). Alignment is everything.