Main idea

Read literally, the phrase announces software without defects — which no team ships, and the objection lands immediately. The goal is elsewhere: zero known defects left undecided.

The unknown stays out of reach. What is targeted is the permanent, organized acceptance of defects we know about. When a signal comes in — a report from support, a regression spotted on an application like My Porsche — the team decides: is it a defect? If so, we fix it. If not, it leaves defect management: improvement, capability request, misunderstanding, interesting subject but out of priority.

What the rule forbids is the third state: "we know it's a defect, we're keeping it in a list for later." A known defect kept without a decision has stopped being a software defect; it is a defect of decision.

Why it matters

This turns around the most common objection. We aren't promising perfection, we are forbidding an intermediate state — and that intermediate state is perfectly achievable.

It also shifts the measurement. We no longer count the product's defects, we count known defects without a decision. The first number depends on the production system; the second depends only on the organization.

Nuances and limits

The rule says nothing about the quality of the decisions taken. A team that massively requalifies things as non-defects satisfies the letter while emptying the meaning.

It bears only on the known: a poorly instrumented product, without structured support, shows few known defects without having fewer.

Open questions

• How do you spot a convenient requalification, which closes the decision without treating the pain?