My father was Quality Manager in a company that produced card board boxes for
cigarettes, pralines and stuff.

When he tested (i.e. inspected) a batch of boxes, he took a sampling and checked various criteria like the coloring the alignment of different colors.

Then there were a couple possible options:

• If almost no problems were found, the batch was shipped to the customer.
• If some problems where found, people had to go through all of the batch and sort out the bad ones. The good ones got shipped to the customer.
• If to many of the samples were bad, the complete batch was scrapped.

Of course scrapping a production batch is expensive and a lot of effort was made to avoid it. But it was a valid option to prevent unusable products to show up at the customers door step, which was the wortst thing that could possibly happen.

In software development I most of the time see a process which only consideres the first two options after testing:

• If there are no, or very few bugs the software gets shipped.
• If there are to many bugs the bugs get fixed and the software gets tested again.

Often this gets iterated until the first option is achieved.

There are good reasons for the difference of course. Scrapping a piece of software is very expensive. Most of the time way more expensive then scrapping even lots of palettes full of card bord boxes.

But there are cases where the third option should be considered.

What if you have very few testers, compared to developers? What if the developers produce really bad code? What would happen if you tell them:

"We gonna look at 2% of the stuff you deliver. And if we find more then x bugs the complete feature will get scrapped. We won't accept a fixed version. We require a complete new version and we want to know what you will do differently this time to ensure the next version is way better then then this one."

Of course this puts a lot of pressure on the developers. It's certainly very frustrating to get the work of weeks rejected like this. Certainly nothing you want to do with a healthy team that had a single bad sprint.

But maybe an option when a team constantly fails to deliver shippable software and you only pile up crap without making progress.