The Physics of Bugs, round 2, some implications

Principle 9: QA is not engineering's sphincter, only engineering can deliver quality

I've worked for many companies where QA was treated as the gatekeeper. It's perfectly natural for QA to function as that last step. But all too often, engineering falls into the trap of thinking that it's QA's job to make sure there's quality, that its the job of QA to keep engineering from delivery a shitty product, that QA is a sphincter muscle to keep the company from pooping its pants.

If engineering ships shit, that's on engineering, not QA. Engineering has to make sure they're delivering quality long before QA sees a single piece. That's why Code Reviews are critical to have, I find 9 bugs in my personal pre-push code reviews long before QA ever sees it and finds 1.

Principle 10: The faster the code, test, fix cycle can run, the faster engineering can develop.

Investments in Continuous Integration, Unit Testing, Test Banks and Continuous Deployment all pay for themselves in subtle ways. If you don't have that stuff, you're paying a continuous tax on your development. It's worth the investment, hire an engineer and devote them to engineering infrastructure, because if something is everyones job, it's no ones job.

Principle 11: If you can't go from production back to a specific state of the source code, you are just incompetent.

I worked for a company that thought they could rebuild production. Nope! Turns out that their Artifactory system was built to purge artifacts after 100 revisions. So even with all the instructions in the world, they could never reproduce a production bug.

Well run operations can tie production back to a specific git hash.