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:


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:


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.