Tradition Is Just an Inherited Hypothesis

You keep doing things nobody can justify anymore. Traditions are solutions that outlived their problems. Here's a test for what to keep, adapt, or discard.

Blindly following tradition means letting people from the past make decisions for the present. People who lived under different constraints, solved different problems, and knew less than we know now. That is the whole definition, and it sounds like an indictment.

It reads like a case for throwing everything old away. It isn't one. Some inherited decisions are still the best answers available, and the people most eager to torch them tend to rebuild them badly.

You know the moment that brought you here. You asked why the report gets printed and filed, why the deploy waits for Thursday, why the firstborn takes over the family business, and the only answer in the room was "we've always done it this way." Now you're stuck between two identities you don't want: the obedient one who never asks, and the arrogant one who discards whatever they can't justify in ten seconds.

There's a third position, and it starts with seeing what a tradition actually is.

Why Smart People Keep Rules Nobody Can Explain

Why do people blindly follow traditions? Because following is cheap and questioning is expensive.

Traditions offer belonging, they save you thousands of small decisions, and they carry compressed judgment from people who paid for it the hard way. "We've always done it this way" is a logical fallacy,¹ and it is also, on many days, a decent bet.

That deserves to be taken seriously. Anyone who tells you tradition is just laziness has never inherited anything worth keeping: a recipe, a craft, a working legal system. The pro-tradition camp is right that inherited practice contains knowledge nobody alive can fully articulate.

But look closely at what that knowledge is. A tradition never starts as a tradition.

Every Tradition Started as a Solution That Worked

Someone faced a problem. They solved it with the best tools their constraints allowed.

The solution worked, so people repeated it, and repetition made it normal, and normal made it invisible. A generation later the problem is forgotten and the solution is still running.

Problem, solution, repetition, ritual. That's the whole life cycle.

When I owned a courier service, the de facto standard for reaching drivers on the road was the two-way radio. The radio solved a real problem: dispatch had no other way to talk to a moving vehicle. It was the correct answer under the constraints that existed.

Then mobile phones became affordable. Better experience, less hassle, lower overall cost, for the same problem.

The day that happened, the radio stopped being a solution and became a habit, and nothing about the radio announced the change. Habits never announce their own expiration.

The radio was never wrong. It was right under constraints that quietly stopped existing.

That's the thing to hold on to: a tradition is an inherited hypothesis. Somebody's claim, frozen into practice, that this is the best available answer to a problem.

The claim was probably true when they made it. Whether it is still true is a question nobody assigned to anyone.

A hypothesis can advise you. It cannot command you.

Chesterton Stopped One Step Too Early

The classic advice for this situation is Chesterton's fence.² Someone walking down a road finds a fence blocking it, sees no reason for it, and wants it gone. Chesterton's rule: if you don't know why it's there, you may not remove it. Go learn what it's for, then decide.

Good rule. Half a procedure.

Understanding the fence tells you what problem it solved. It tells you nothing about whether that problem still exists, or whether a better answer became possible while nobody was looking. Plenty of people trace a fence to its origin, feel the glow of due diligence, and leave it standing out of the same inertia they started with.

The fence has a second flaw, and its critics have circled it for years: it puts the entire burden of proof on whoever wants change, while the status quo never has to defend itself. Treating tradition as a hypothesis fixes the asymmetry. The old answer and the new candidate both have to argue from today's conditions, and neither gets grandfathered in.

Which means respecting a tradition and questioning it stop being opposites. Done properly, they are the same act.

And notice what just happened, because it's the whole method in miniature. Chesterton's fence is itself a fence: a rule from 1929, built under 1929 constraints. Trace it back and the problem it solved, reformers tearing down what they didn't understand, is still alive. But a better answer became possible while nobody was looking. So the fence gets the exact treatment it prescribes: understood first, then improved. Not kept, not torn down. Adapted.

The Keep, Adapt, or Discard Test

Run any inherited practice, from your standup format to your holiday plans, through three questions:

1. What problem did this solve? Dig until you find one. If you can't find any, you haven't earned an opinion yet; that's Chesterton's rule, and it still applies.
2. Does the problem still exist? Check it against today's constraints and today's knowledge, at your scale, in your situation.
3. Would you invent this today? Facing the current version of the problem with current tools, would you arrive at this same solution?

Three verdicts fall out. Keep, when the problem is alive and the old answer still wins the comparison. Adapt, when the problem is alive and a better answer has become possible. Discard, when the problem itself is gone.

The courier radios were an adapt: reaching drivers never stopped being the problem, the radio just stopped being the best answer to it. Most workplace fights are adapts too. And keep is a real verdict this test produces, or the whole thing is just iconoclasm with paperwork.

Take the Thursday deploy from the opening. Question one: it almost certainly solved a disaster, a bad Friday release with nobody around all weekend to fix it. Question two: that depends entirely on your shop. If rolling back still takes hours and a human, the problem is alive and Thursday is a keep. If a rollback is one command, the constraint is dead and the rule is running on inertia.

Same practice, opposite verdicts, because the test reads your constraints, not the practice's reputation. A test rigged against tradition would give both shops the same answer.

One warning about question one. Practices get overloaded. They start out solving the stated problem, then quietly pick up a second job nobody wrote down, and the second job is usually social.

Picture a family running the test on their exhausting holiday dinner. What problem does it solve? Feeding everyone, obviously, and a restaurant does that better, so they book a table.

The food improves, and the afternoon together disappears, because feeding people was never the dinner's real job. The real job was the second one: all that cooking pulled three generations into one kitchen and kept them talking for hours.

So dig past the first problem you find. Dropping a practice is only safe once you've found every job it was doing, and the last job you find is usually the one nobody could articulate.

The Neighbor Who Swapped a Verdict for an Evaluation

Where I grew up, leaving the country to live somewhere else was frowned upon. Staying meant loyalty. Leaving meant a quiet kind of betrayal.

Nobody defended this position, because verdicts that arrive pre-decided don't take questions.

As a kid, I talked about it with an older neighbor, a sharp man who had lived abroad for years. He didn't rage against the custom.

He replaced it with an evaluation: staying or leaving is a personal decision, based on how comfortable and how advantageous life is here versus somewhere else. Weigh both honestly, then choose.

Look at what he did. He recovered the question the tradition had fossilized (where should a person live?) and re-derived the answer from current conditions.

And one detail made it stick with me permanently: he was my neighbor. His evaluation had brought him back.

Same verdict the tradition demanded, reached in a way that made it his. That's a keep.

A verdict you inherit belongs to the past. The same verdict, re-derived, belongs to you.

I have looked at standards differently ever since that conversation.

When to Run the Test

The test creates its own tension, and it's one I set up at the start. Questioning is expensive.

That was the whole reason blind following made sense as a bet, and it doesn't stop being true now that you have a procedure. Run the three questions on everything you've inherited and you'll spend the exact decision budget traditions exist to save.

So you can't audit everything. You need a trigger.

Look at what actually killed the courier radios. Not a scheduled review, not a moment of philosophical clarity. A constraint died: phones got cheap enough to put one in every driver's pocket.

The practice never announced its expiration, but the death of the constraint announced itself just fine, in a shop window, with a price tag.

That's the trigger. Don't audit practices on a schedule. Audit them when a constraint dies.

Constraint deaths rarely arrive labeled; they arrive as something new turning cheap, fast, effortless, or possible at all. When one of those shows up anywhere near a tradition, that's when the third question, would you invent this today, is most likely to have a new answer.

Then AI Deleted the Problems

For most of history the trigger fired rarely. A constraint died once a decade, you re-tested the few practices built on it, and life went on. You could treat all this as philosophical hygiene, something to practice on career scripts and holiday plans.

Then AI took a whole column of constraints down at once: the cost of writing, of drafting, of coding, of searching, of translating. Every practice resting on any of those constraints came due for the test in the same two-year window.

The philosophical exercise turned operational, because AI does something stranger than speeding up your workflows. It deletes the assumptions they were built on.

Most software process is rationing. Specs, review chains, estimates, the roadmap fight: they exist because building was expensive and mistakes were slow to undo. Those were the constraints.

When code becomes cheap to write and cheap to rewrite, a process built to ration a scarce thing keeps rationing a thing that stopped being scarce. Ask the test's second question, does the problem still exist, and the honest answer is turning into no all over your company, silently, with every process still running.

One of mine is already gone. Every working session with an AI agent used to end in a handoff ritual: write up what was done, what was decided, what the next session needed to know, because the next session woke up with amnesia. Then context compaction got good enough that sessions started carrying their own memory, and the amnesia mostly stopped.

The ritual quietly lost its job. Verdict: discard. This constraint didn't die in a shop window; it died in a release note.

Not every process has lost its problem, though. A review that catches the mistake no rewrite can undo, the leaked credential, the corrupted database, guards a problem that's still alive. The test will say keep there, which is exactly why you can trust it when it says discard.

And the same cheapness produces the opposite failure. Stéphan Tulkens recently named it Chesterton's gap:³ when code costs almost nothing, people start filling every gap they see, shipping features nobody asked for, without wondering whether the gap was a decision.

Absences are fences too. The discipline cuts both ways: understand before you remove, and understand before you fill.

AI also creates a case the test's first question never had to face: fences with no author. An agent generates code, the code ships, and now a structure exists that nobody chose on purpose. Dig all you want; there is no forgotten problem at the bottom and no one to ask. Chesterton's rule, read literally, would leave you standing in front of that fence forever.

The way through is that a hypothesis you can't recover, you can still reconstruct. Ask what problem this thing would have to be solving for it to make sense, write that down as the hypothesis, and run questions two and three against it. Same test, on your best guess instead of somebody's memory, and held more loosely for exactly that reason.

The acceleration does one more strange thing: it barely lets tradition set. The life cycle that used to take a generation, problem, solution, repetition, ritual, now runs in weeks, and a louder paradigm is usually at the door before the ritual stage even arrives.

Which flips the test's default direction. For most of history it defended you against inertia. At AI pace it mostly defends you against novelty.

I keep meeting this with multi-agent workflows. Fanning work out to parallel sub-agents is the loudest paradigm in AI-assisted building right now, and it lands squarely on my own trigger: a new capability, fast, and barely needing me while it runs.

So the test was due, and I've run it more than once. The tasks I need done usually don't decompose into parallel lanes, so facing them today, with every tool on the table, I'd still build the workflow I already have. That's question three answering yes.

Verdict: keep. And here's the strange part: the workflow I was defending was a few months old. A tradition so young it barely qualified for the name, and it still beat the new paradigm.

The test doesn't score age in either direction. Appeal to novelty is the same fallacy as appeal to tradition in this year's clothes: nobody gets grandfathered in, and nobody gets fast-tracked for being new.

Whichever direction you fail from, you're authoring tomorrow's traditions right now. The workflows you're improvising around AI this year will be somebody's "we've always done it this way" in five. The kindest thing you can do for whoever inherits them is to attach the problem statement.

It fits in one line: this exists because X. When X stops being true, kill it. That's question one answered in advance and question two pre-authorized. Whoever inherits the practice inherits permission to end it.

Somewhere along the way, that became my default relationship with tradition. I don't usually inherit them anymore. I create new ones, and each one is the same test run forward: state the problem, pick today's best answer, and expect someone later to out-argue it.

That includes the one you just read. This test exists because constraints now die faster than the practices built on them. When that stops being true, or when someone out-argues these three questions, kill it. It's not a rule. It's a hypothesis with its problem statement stapled on.

The people who started your traditions were never traditionalists. Whoever bolted the first radio into a courier van was solving a live problem with the best tool of their moment.

Repeating their solution honors nothing. Repeating their act is the tradition.

Rabbit Hole

More on this subject

• You're Building a Stone Cathedral Out of Concrete: See how new capabilities expose old forms that no longer fit.
• Your Job Already Changed. You Just Didn't Notice.: Apply the same test when AI quietly changes what good work requires.

See this concept in another subject

• Static UI Isn't Legacy. It's Institutional Memory You Can Click. (Free tool included): See why an old form may still solve a hidden coordination problem.