The Keep, Adapt, or Discard Test for Inherited Practices
Updated
Knowledge on this page was mainly distilled from Tradition Is Just an Inherited Hypothesis.
The keep, adapt, or discard test is a three-question evaluation for any inherited practice, from a standup format to a holiday tradition to a company deploy policy. It treats every tradition as an inherited hypothesis and asks whether the hypothesis still holds under current conditions.
The Three Questions
- What problem did this solve? Dig until you find one. If you cannot find any problem, you have not earned an opinion yet. This is the Chesterton's fence step, and it still applies.
- Does the problem still exist? Check it against today's constraints and today's knowledge, at your scale, in your situation.
- Would you invent this today? Facing the current version of the problem with current tools, would you arrive at this same solution?
Three Verdicts
Keep when the problem is alive and the old answer still wins the comparison. Adapt when the problem is alive but a better answer has become possible. Discard when the problem itself is gone.
Most inherited practices land on adapt. The courier radio example illustrates this: reaching drivers on the road never stopped being the problem, but the two-way radio stopped being the best answer once mobile phones became affordable. Workplace process arguments are usually adapts too. And keep is a real verdict this test produces, or the framework would be nothing more than iconoclasm with paperwork.
Same Practice, Opposite Verdicts
Consider a Thursday deploy rule. Question one: it almost certainly solved a real disaster, a bad Friday release with nobody available over the 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. The test reads your constraints, not the practice's reputation.
Watch for Hidden Jobs
Practices get overloaded. They start solving the stated problem, then quietly pick up a second job nobody wrote down, and the second job is usually social. A family running the test on their exhausting holiday dinner might conclude that feeding everyone is the stated problem and a restaurant solves it better. But the food was never the dinner's real job. All that cooking pulled three generations into one kitchen and kept them talking for hours. The social function was invisible because nobody articulated it.
So dig past the first problem you find. Dropping a practice is only safe once you have found every job it was doing, and the last job you find is usually the one nobody could articulate.
Q&A
How is this different from a standard cost-benefit analysis?
A cost-benefit analysis compares options at a single point in time. This test starts by recovering the original problem, checking whether that problem still exists, and then comparing solutions under current constraints. The historical recovery step is what prevents you from optimizing for a problem that is already gone.
What if nobody remembers why the practice exists?
That is exactly the situation question one addresses. If you cannot find the original problem, you do not yet have enough information to act. Chesterton's rule still applies: learn what it was for before deciding. The test does not give you permission to discard what you do not understand.
Can a practice be both a keep and an adapt at the same time?
Not for the same problem, but a practice can serve multiple problems. It might be a keep for one job it does and an adapt or discard for another. The holiday dinner example shows this: the feeding job was ready to discard, but the social-bonding job was a keep nobody had identified.
Why does the article say most practices land on adapt?
Because the underlying problems rarely vanish entirely. What changes are the constraints and tools available to solve them. When the problem is alive but better answers have emerged, the verdict is adapt. Pure discards, where the problem itself disappeared, are less common than constraint shifts that open better solutions.
When should you actually run this test?
Not on a schedule. The recommended trigger is a constraint death: when something new becomes cheap, fast, effortless, or possible for the first time. When that shift touches a tradition, question three (would you invent this today?) is most likely to have a new answer. Auditing everything at once would spend the exact decision budget traditions exist to save.