What Makes a Constraint Good?

Good constraints clarify design, protect coherence, and create a viable space for exploration without collapsing into arbitrary mandates.

More in the Constraints Series

Bad Constraints Are Everywhere

Software teams are surrounded by constraints that are poorly stated, poorly justified, or poorly understood.

Sometimes the bad constraint sounds like a requirement:

We need microservices.

No, you do not. That is not a requirement. That is a proposed implementation strategy, and often not even a good one.

Sometimes the bad constraint sounds like governance:

Every service must use this framework.

Maybe. But if the rationale is unclear, the operational tradeoffs are ignored, and the framework itself becomes the center of gravity, then what you have is not clarity. What you have is a mandate in search of a justification.

Sometimes the bad constraint sounds respectable because it borrows the language of reliability:

Everything must be five nines.

Everything? At what cost? Under what load profile? For which capabilities? With what business consequences if the target is missed? Without such questions, this kind of statement usually amounts to availability fantasy.

Bad constraints often share a common trait: they create cost, rigidity, and confusion without producing corresponding clarity.

Good Constraints Create A Viable Design Space

In Liberating Constraints, I argued that the right kind of constraint behaves like a fence around a playground. It gives people the confidence to explore.

That image still works.

A good constraint does not suffocate exploration. It makes exploration safer, clearer, and more productive. It narrows the problem space enough to support coherent design while leaving sufficient freedom to discover the best solution within that space.

This matters because design is not the same thing as choosing tools.

A good design keeps options open where options should remain open. It closes them where needless variability would undermine coherence, reliability, or simplicity. That is one reason design before technology matters so much. If you start with tools, you usually inherit constraints accidentally. If you start with design, you can adopt them deliberately.

What Good Constraints Tend To Have In Common

No single checklist will eliminate the need for judgment. Even so, good constraints usually share a few recognizable traits.

Clarity

A good constraint is clear enough that reasonable people can interpret it in substantially the same way.

If a standard, requirement, or policy must be endlessly translated before anyone can implement it, then it is not doing its job. Ambiguity multiplies cost. Teams fill in the gaps with assumptions. Assumptions diverge. Systems drift.

Clarity does not require excessive detail. It requires that the intent, scope, and meaning of the constraint be understandable.

Relevance

A good constraint is tied to a real problem, risk, or value concern.

This seems obvious, but software organizations routinely impose rules that survive long after anyone remembers why they were introduced. A team inherits a pattern, a framework, a process, or a reliability target, and before long the thing is treated as sacred. Meanwhile the original context disappears.

A useful constraint should answer a basic question:

What problem does this help us avoid, or what value does this help us preserve?

If no one can answer that question, skepticism is warranted.

Proportionality

A good constraint is proportionate to the cost of enforcing it and to the risk it is meant to manage.

This is where many organizations get into trouble. They impose heavyweight controls on low-risk concerns and then wonder why delivery slows to a crawl. Or they set heroic operational targets on systems that do not justify the expense.

A payment system, a medical system, and an internal reporting tool do not all deserve identical constraints. Treating them as though they do is not rigor. It is category confusion.

Stability

A good constraint is stable enough to design against.

This does not mean it must remain unchanged forever. It does mean that it cannot be in a constant state of churn. Teams cannot create coherent systems while their basic design boundaries shift every few days.

Interfaces need some durability. Expectations need some continuity. Decision-making needs some firmness.

An unstable constraint turns architecture into improvisation.

Outcome Orientation

A good constraint focuses on outcomes, interfaces, or properties rather than gratuitous implementation detail.

This distinction matters.

Compare these two statements:

External clients must be able to integrate through a stable, versioned contract.
All teams must use Framework X and deploy on Platform Y.

The first expresses a design concern. The second prematurely collapses design into a specific implementation choice.

Sometimes a technology decision really is constrained by reality. Fine. But we should at least be honest about when we are constraining a property of the system and when we are merely standardizing convenience or consolidating expertise.

Those are not always the same thing.

Verifiability

A good constraint is testable, observable, reviewable, or otherwise verifiable.

If compliance with a constraint cannot be checked in any meaningful way, then the constraint is likely to devolve into theater. Teams will claim alignment. Reviewers will infer alignment. Eventually reality intrudes.

Good constraints lend themselves to validation.

An interface contract can be tested.
A latency objective can be measured.
An ownership boundary can be reviewed.
A deployment requirement can be automated.

When a constraint cannot be verified, it often cannot be trusted.

Generativity

A good constraint enables useful action.

It should help teams move. It should support composability, implementation, communication, or decision-making. It should reduce wasteful debate and make the next responsible step easier to identify.

This is one reason I remain skeptical of constraints that sound impressive but produce no tangible design advantage. If a constraint does not improve clarity, reduce risk, strengthen interfaces, or support maintainability, then why exactly is it there?

Good constraints do not merely restrict. They cultivate the generation of better options while preserving design integrity.

Common Failure Modes

Bad constraints tend to fail in predictable ways.

Vague Constraints

These sound serious but offer little practical guidance.

Build for scale.
Make it secure.
Ensure flexibility.

Scale how? Secure against what? Flexible in relation to which kinds of change?

Without definition, teams are left to substitute instinct for design.

Solutionized Constraints

These masquerade as requirements while smuggling in implementation decisions.

Use microservices.
Put it on Kubernetes.
Standardize on event sourcing.

Perhaps those choices will prove wise in some contexts. But they are not automatically evidence of good design. They may be valid responses to constraints. They are not the same thing as the constraints themselves.

Jumping directly to such prescriptions usually means the design work has been skipped.

Totalizing Constraints

These apply one rule to everything regardless of context.

Every system must meet the same uptime target.
Every integration must use the same pattern.
Every team must follow the same approval path.

Uniformity can sometimes reduce complexity, but indiscriminate uniformity often creates more of it. Good constraints must account for differences in domain, risk, tempo, and operational importance.

Stale Constraints

These once made sense but no longer do.

A team grows. The business changes. The integration landscape shifts. Regulatory expectations evolve. Yet the old rule remains, defended mostly by habit.

Stale constraints are dangerous because they often retain institutional legitimacy while quietly losing practical value. They can even begin to incur a negative return on investment while still being treated as sacred.

A Few Questions Worth Asking

When evaluating a proposed constraint, I would start with questions like these:

Is the constraint optional or mandatory?
What problem does this constraint address?
What challenges might it introduce?
What failure mode or source of volatility does it contain?
Does it constrain an outcome, an interface, or merely an implementation preference?
Is it clear enough to interpret consistently?
Can we verify whether we are complying with it?
Is the cost of this constraint proportionate to the risk or value involved?
Will this improve composability, maintainability, or operational clarity?
Is this constraint stable enough to design against for the next meaningful stretch of time?

Any team that cannot answer such questions is probably not dealing with a well-formed constraint.

Closing

A good constraint is not merely restrictive. It is clarifying.

It reduces ambiguity without destroying optionality. It creates boundaries that support exploration. It improves the odds that independent teams and components can still produce a coherent whole. It helps contain volatility rather than amplifying it.

That is the point.

The software industry does not suffer from a shortage of strong opinions, preferred tools, fashionable architectures, or mandatory frameworks. It suffers from a shortage of disciplined thinking about which constraints actually matter, why they matter, and how they should shape design.

Good constraints do not eliminate judgment. They canonize good judgment, they maintain design integrity, and they help teams make good decisions.

Connect