When Is It Time to Commit?

There is a recurring temptation when solving difficult problems: decide what kind of problem we're looking at as quickly as possible.

Sometimes that's exactly what we should do. A server is down, a pipe is leaking or a deadline is approaching. We know enough to act, and additional reflection may simply increase the cost of waiting.

Other problems punish early certainty.

We encounter a few examples, notice a pattern and build a rule around it. The rule works well enough that we stop examining the assumptions underneath it. Then an unusual case arrives and we have to decide whether the case is wrong, the rule is incomplete or the situation has changed.

I've often described this as premature closure, although even that phrase carries a bias. It assumes that remaining open would have been better.

Sometimes closure is exactly what makes action possible.

The harder question is when to commit and what kind of commitment the available evidence has earned.

That distinction matters because decisions don't all close possibility in the same way. Some are cheap to reverse. Others create dependencies, expectations or physical changes that make returning difficult. Choosing a restaurant with incomplete information is different from pouring a foundation with incomplete engineering. Publishing a tentative interpretation is different from writing that interpretation into a policy thousands of people will have to follow.

So uncertainty alone doesn't tell us to wait.

We also need to know the cost of waiting and the cost of being wrong.

This is one place where I've become more cautious about carrying lessons between domains. Overfitting in machine learning, premature optimization in software, dogma in ethics and impulsive decisions in personal life can all look superficially similar because each involves some relationship between limited information and a committed response.

That resemblance can generate a useful question.

It doesn't establish that they're the same failure mode.

Each domain has different evidence, different consequences and different ways of correcting mistakes. An optimization can be benchmarked. A technical design can sometimes be rolled back. An ethical decision may affect another person in a way no later correction can fully undo.

The analogy gets us to the question.

The domain has to answer it.

This also changes how I think about coherence. I've sometimes described coherence as though it were a universal behavior through which systems maintain themselves while adapting. That definition is attractive because it travels easily. It can be applied to organizations, software, conversations, beliefs and living things.

Traveling easily isn't evidence that the concept explains all of them.

A simpler use of coherence is enough for most of what I actually need from it. Something is coherent when its parts make enough sense together for the purpose we're examining. A software architecture can be coherent because its components have understandable responsibilities. An explanation can be coherent because its claims don't contradict one another. An organization can have coherent procedures because people can understand how decisions move through it.

Those are related uses of a word, not necessarily manifestations of one underlying process.

The interesting part begins when coherence encounters change.

A design that made sense under one workload may become awkward under another. A procedure built for five employees may fail with fifty. An explanation that fit the available evidence may encounter evidence it can't accommodate.

Now we have choices.

We can preserve the existing structure and treat the disturbance as noise. We can modify the structure. We can replace it. Sometimes we discover that the apparent contradiction came from misunderstanding the new information and nothing needed to change at all.

Deviation doesn't tell us which response is correct.

It gives us something to investigate.

That is one reason constraints matter. I've previously been tempted to place structure and adaptability on opposite ends of a spectrum, as though more of one necessarily means less of the other. In practice, constraints can make adaptation possible.

A database schema constrains what can be stored while making the stored information easier to use. A building code limits available designs because certain failures have already been expensive enough to justify the restriction. A musical form can constrain composition while creating a space in which enormous variation remains possible.

The question isn't simply how much constraint exists.

It's what the constraint is preserving and whether the reason still applies.

This becomes especially important when we inherit a system. An unfamiliar rule can look like unnecessary complexity because we didn't witness the failure that produced it. Removing the rule may simplify everything beautifully until the old failure returns.

The opposite mistake is just as easy. A rule survives for decades, everyone assumes it must exist for a reason, and nobody discovers that the condition it addressed disappeared years ago.

Recover the problem before deleting the solution.

Then let the problem itself have another turn.

Compression creates a similar challenge. We can't carry every detail of everything forward, so we summarize, categorize and abstract. That isn't merely an unfortunate limitation. Abstraction is what lets information travel beyond the situation that produced it.

A newspaper article compresses hours of interviews and observation into something a reader can encounter in minutes. Documentation compresses the experience of the people who built a system. A metric compresses many observations into a value that can be compared over time.

Every one of those transformations preserves something and discards something.

The danger isn't compression itself.

It's forgetting what was discarded.

A summary doesn't necessarily preserve “causal shape.” Sometimes the summary contains the wrong causal explanation. A memory isn't guaranteed to preserve the most actionable part of an experience. A machine-learning model that generalizes isn't simply performing some ideal form of structural preservation.

Those stronger claims sound satisfying because they let many different processes fit beneath one abstraction.

The abstraction becomes cleaner as the objects become less distinct.

That's exactly where I now want to slow down.

If I say that a healthy system preserves relational structure while discarding instantiation, what observation would show me that I'm wrong? If every successful abstraction counts as structural preservation and every unsuccessful one counts as losing the wrong structure, I've built an explanation that can absorb every result.

It no longer teaches me much.

A more useful question is specific: what did this representation preserve, what did it discard and what happens when the discarded information turns out to matter?

That question travels surprisingly well without requiring the mechanisms underneath it to be the same.

It also gives us a better way to think about feedback. Feedback doesn't automatically improve a system. People misinterpret feedback. Metrics create incentives. Customers can be wrong about why they dislike something. Experiments can be badly designed. Organizations can collect enormous amounts of information while learning very little from it.

Feedback doesn't interpret itself.

What matters is whether there is some path through which observations can challenge the model being used to interpret them.

Even then, correction isn't guaranteed.

This is where commitment and revisability have to coexist. We can't wait for complete information because complete information usually doesn't exist. At some point we build the bridge, publish the article, adopt the policy, deploy the software or make the decision.

Then reality gets another turn.

That doesn't mean every decision should remain permanently negotiable. Some commitments become valuable precisely because people can rely on them. Standards lose usefulness if they change every time somebody encounters an inconvenient case. Relationships can't function if every promise is continuously reopened for reconsideration.

Revisability needs boundaries too.

The challenge is to make those boundaries appropriate to what is at stake. A low-cost hypothesis can remain highly provisional. A safety-critical rule may require much stronger evidence before it changes. A decision affecting another person's rights should not become an experiment whose learning costs are simply transferred to them.

Different objects earn different amounts of caution.

This is where ethics enters the picture, although I would no longer describe ethics as “load-bearing infrastructure.” That's a useful metaphor, not an explanation.

Honesty can improve the quality of information available to a group, but honesty matters for reasons that can't be reduced to information flow. Compassion may help us notice consequences we would otherwise ignore, but describing compassion as “bandwidth expansion” throws away too much of what compassion means in order to make it fit a technical vocabulary.

The technical analogy can help me notice something.

Then ethics gets to remain ethics.

The same restraint applies to the idea of letting a system teach us. There are situations where variation and experimentation produce solutions nobody anticipated. There are also situations where the cost of letting the system discover the answer through failure is unacceptable.

We don't need a bridge to learn through collapse.

We don't need people to repeatedly experience preventable harm so an institution can become wiser.

Some learning should happen in simulation, testing, historical study, controlled experiments or by inheriting knowledge from people who already paid for the lesson.

Reality teaches.

We still get to choose where the tuition is paid.

So I no longer think the designer's job is simply to create conditions in which coherence can emerge. Sometimes the designer should impose a constraint. Sometimes the leader should make a decision before everyone agrees. Sometimes the engineer should refuse an experiment because the failure mode is already understood.

Other times the right response is to leave room.

The skill is not openness or control by itself. It is knowing what has already been learned, what remains uncertain, what can safely be discovered through experience and what should not have to be learned again.

That judgment will never be perfect.

We will sometimes commit too early and discover that our model was incomplete. Other times we'll remain provisional long after the evidence justified action. Occasionally we'll protect an inherited constraint only to discover that we were preserving a solution to a problem that no longer exists.

The answer isn't to avoid commitment.

It's to make commitments that resemble what we actually know.

Strong where the evidence is strong.

Provisional where the evidence is incomplete.

Reversible where mistakes are likely.

Stable where others reasonably need to rely on them.

And open to contradiction wherever reality still has something to say.

Perhaps the most useful lesson from all these systems isn't that they obey the same underlying rule.

It's that abstraction itself is a commitment.

The moment we say, “These are all examples of the same thing,” we've compressed several different objects into one explanation. That may reveal something useful, or it may hide the distinctions we needed most.

So the abstraction should have to earn its keep too.

Use it.

Test it.

Then return to the objects and see what it left out.