1. 7
    1. 2

      Assign separate staff for separate stages. At a minimum, the person who wrote the code shouldn’t test it, nor should they operate it, but ideally a separate staff of specialized people test and operate the software. […] The third piece of advice might seem obvious, but I’ve been a member of several organizations where engineers are allowed to review their own code. If you have the same group of people doing a separate stage, you don’t have a separate stage, you’ve just drawn an extra box that isn’t meaningful. If the people writing the code also perform the testing, you don’t have a separate testing stage. The same is true if you have programmers operating the software.

      I don’t understand why the author thinks this is obviously a good idea. It runs counter to both my intuition and everything I’ve read about software project management best practices. Is the argument meant to be that it ensures sufficient documentation? Because, based on what I’ve read, it doesn’t, but rather just leads to delays, cost overruns, and preventable issues in production.

      1. 7

        It’s like proofreading a paper, if I write a paper, I know what it’s supposed to say, and I expect it to say that, so I often overlook mistakes, omissions because I perceive what I expect rather than what’s actually there. I often miss glaring and simple errors or interpretations I didn’t think of initially.

        By forcing a social barrier, I ensure that someone other than me can understand what I mean. Unlike high school English class, in software this often doesn’t matter (there’s no teacher with a red pen at the end of the line, as long as I can use what I wrote, it works), but this makes me an unknown linchpin in the system. If I get stuck “camping” for an extra week due to inclement weather, or leave, or are reassigned, suddenly the fact that I wrote something only I can use becomes a real issue. Without enforced barriers between people at explicit stages of the process, a company has no idea how many couplings of this form they might accidentally have, and companies don’t like unknowns, for good reason.

        Also, anecdotally, having worked at an org that separates dev/test/ops and ones that don’t, my tests never find bugs in my code. Other people’s do. I never find missing pieces in my procedure documentation, other people do.

        1. 1

          All of this can be addressed by having someone else on the team review all PR’s. I don’t see how enforcing a team segregation and low bandwidth, high latency communication channel helps.

      2. 4

        I don’t know why either, but it seems popular. At my previous job, old management, we (my team) worked closely with QA, often tossing code their way even before we were “officially” done for early and quick feedback. For a decade, on time, smooth deployments, no major bugs in production. New management came in, and instant silos! No more talking with QA! We must develop in isolation. Instant delays, horrible deployments and bugs, oh my!