I once received a job offer from my write-up about the 200-line rule. That was an unexpected result from an article about file size.
I no longer follow the rule.
Both things can be true. The article gave someone something concrete to evaluate. The rule itself doesn't have to become a permanent part of my identity because it worked as a piece of writing.
There is a problem with a rule you can measure easily: eventually, the measurement can become the thing people optimize. A file has 240 lines, so someone splits it. The check passes. Whether the next person can understand the code is a different question.
I still want rules that make work easier to understand and check. I just want the reason close enough to the rule that someone can challenge the implementation without having to argue against the entire goal.
Take one rule you already have
Choose something your team actually enforces. It could be a code limit, a required reviewer, a naming convention, or a policy that every change needs a ticket. Start with one that causes arguments or repeated exceptions.
Put this beside it:
Rule:
What are we protecting?
What failure would we notice without this rule?
What does the rule actually measure or require?
Where can someone comply without achieving the goal?
When is an exception reasonable?
What evidence would justify changing or removing the rule?
Who can approve that change?
You don't need a policy database. A paragraph beside the configuration or in the team's working instructions is enough. If the rule is in a linter, link from the nearby comment to the explanation. Don't hide the reason in a chat nobody will find.
Here is a hypothetical file-size policy filled out that way:
Rule: Flag source files longer than 200 lines for review.
Goal: Keep a change understandable without hunting through unrelated code.
Failure: One file mixes unrelated responsibilities and becomes risky to edit.
Measurement: Physical lines, which are only a rough clue.
False success: Split a coherent function across files just to pass the check.
Exception: A longer file with one clear responsibility and useful tests.
Reconsider when: The limit keeps causing splits that make changes harder to follow.
Decision owner: The maintainer responsible for this code.
That example is a review exercise, not a recommendation to install a 200-line checker. It makes the gap visible: the goal concerns comprehension; the measurement concerns length.
Try to obey it badly
Ask how someone could satisfy the rule and still produce a result you dislike.
For a mandatory-review policy, they might collect an approval from someone who only read the summary. For a required-ticket policy, they might create a ticket with a title and no explanation. For a test-coverage target, they might execute the lines without checking a meaningful result.
Use an invented example if you need to. This is not an invitation to embarrass a colleague or weaken a safety requirement. You're checking whether the rule asks for evidence of the thing you care about.
Then write a better acceptance check. For the file example, I would ask the reviewer to follow one change from its entry point to the affected behavior. Can they identify the callers? Is there a test for the failure being fixed? Did the refactor make that journey easier?
That takes judgment. A line counter still has a use as a cheap signal, but it cannot answer those questions for you.
Make the exception legible
An exception should say what is different about this case. "We were busy" usually explains the schedule, not the safety of the decision.
A useful exception might read:
This file stays together because the parsing steps share one input contract. Splitting it would require passing intermediate state between modules. The change includes tests for invalid input and each public caller. Revisit the boundary if another feature needs one of those steps independently.
This is an illustrative rationale, not evidence that a particular refactor is correct. The reviewer still needs to inspect the code. But now there is something to agree with or reject.
Some constraints are not yours to waive. A legal requirement, a customer's data boundary, or an authorization check needs the appropriate owner and evidence. Making a rule understandable does not make it optional.
For the next rule your team debates, try adding the reason and one counterexample before adding another exception. The conversation gets more useful when people can point to the failure they are trying to prevent.