1 > 2 > 0, but n ≤ 2
At a recent engineering offsite, someone brought up a useful principle that stuck with me:
1 > 2 > 0
The more I thought about it, the more I liked it. I would add one constraint: never more than two.
Mathematically, it is wrong. Operationally, it is often right. With the added constraint, the full principle becomes: 1 > 2 > 0, but n ≤ 2.
The idea is simple: one system is better than two, and two systems are better than zero. But more than two is no longer intentional duplication; it is drift.
Engineering organizations often treat duplication as an automatic failure. In the long run, it usually is. Duplicate systems create reconciliation work, split ownership, confuse users, and force teams to ask which version of reality is authoritative.
But avoiding duplication is not the same as architectural discipline. Sometimes the bigger failure is waiting for the perfect system while the business need remains unsolved.
One system is the ideal. It gives the organization one source of truth, one ownership model, one interface, and one place to invest. When that system is right, every new requirement and operational lesson strengthens it.
But organizations do not always start there. The current system may not support a new workflow. The domain may still be emerging. The long-term architecture may be clear, but too slow to build first. In those moments, insisting on one perfect system can become a sophisticated form of inaction.
This is where bias for action matters.
Bias for action does not mean moving carelessly. It means making progress through explicit, reversible trade-offs instead of waiting for complete certainty. A second system can be one such trade-off.
A second system can isolate a new workflow, support a new business need, prove a product pattern, or make an emerging domain concrete enough to inform the durable architecture.
The difference between good and bad duplication is intent.
Accidental duplication happens when teams optimize locally without clear ownership or awareness of what already exists. Intentional duplication is a conscious decision to move faster now while preserving the option to converge later.
That requires discipline. My take is: never more than two.
One system is the goal. Two systems can be a deliberate transition. But if you are about to create a third, stop and reevaluate. A third system usually means the organization is no longer learning its way toward coherence. It is normalizing fragmentation.
The operating principle is to move from 0 to 2 when action is more valuable than waiting, then move from 2 to 1 when the pattern is proven. But never drift from 2 to 3 without forcing a decision.
Before creating a second system, ask what this lets you do now that the existing system cannot. Ask what boundary prevents it from becoming sprawl. Ask when you will decide whether to merge it, retire it, or promote it into the durable system.
And before doing something a third time, ask the harder question: are we still experimenting, or are we avoiding convergence?
That is why I like this principle: it embodies both bias for action and engineering discipline. Bias for action moves you from zero to two when waiting is more expensive than duplicating. The engineering discipline moves you from two to one once the pattern is proven. Stopping before the third system is the forcing function: it turns drift into a decision to merge, retire, or simplify.