> I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC.

For electronic engineering this is a known fault mode of inspection.

When the first line inspectors are busy they'll shovel stuff theough with less inspection because there's someone else to do so checking. But now that other person is busy, and they'll shovel stuff through because if the first line of inspectors are doing their job properly it should be okay.

So it's interesting to see this not fail in an indistry tha is data driven and cash sensitive.

It'd be interesting to know what the difference is.

Yeah, lets pretend there is a perfect process and also punish people who own up to mistakes. That is stupidly what most companies do: add more process, make developers stand on their heads. The fact is that certain types of logic errors are likely never to be caught by SCA, code reviews, test cases, or anything else. It's just a fact that bugs are going to get through no matter what. It's is far better to have an environment where fault tolerance is built in AND there is no punishment culture for bringing bugs to light. If you rely on process you will get a) people hiding bugs, b) blame culture c) more disasterous failures.

> The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.

Its interesting to reflect on this statement in the context of Zenefits vs the insurance industry.