Removal conditions

Chesterton’s fence is the most quoted piece of advice in engineering and the least operational. The reformer who finds a fence across a road is told to go and find out why a fence was put across a road before clearing it away, and the advice is right and stops one step short. Knowing why the fence went up in 1974 tells you nothing about whether the reason still holds. You now have a history lesson and the same decision to make, and the person who wrote the history is not in the room.

Look at what the standard artifact for this actually records. An architecture decision record, in the template most teams inherited, has fields for context, for the decision, for its status, and for its consequences. Every one of them is about the past. None of them is about the conditions under which the decision stops being right, so the document arrives in front of a future maintainer as an explanation of a choice they are considering undoing, which is the one form of evidence least likely to stop them. Rationale is an argument the author had with themselves. It was already won.

The addition is one more field and it changes the register of the whole document. Alongside the reason, record what would have to be true before removal is safe. A removal condition turns a decision into a testable claim about the present rather than a report about the past, so taking it out means arguing with a sentence instead of deleting a line. The annotation form our engineering record uses is deliberately plain, a marker naming the decision as load-bearing, the rationale, the alternatives that were rejected, and the requirement that would have to be satisfied for the thing to go.

Our own record carries five of these, and reading them back is instructive because none of the conditions are impossible. The documentation hierarchy can go on the day an equivalent way of surfacing context at the point of decision exists. The abstraction over a third-party service can go when we either commit to that vendor deliberately or build a different abstraction. The two parallel data paths collapse into one the moment we drop either the server-rendering requirement or the offline requirement, and not before. A disabled lint rule comes back when the upstream conflict that forced it off is fixed. Each is a sentence somebody can meet, and meeting it is how the decision retires with dignity instead of being deleted in a cleanup.

The discipline earns its keep now for a reason that did not apply when these records were invented. A model asked to simplify a file will remove what looks redundant, and it is genuinely good at making things look tidy, because tidiness is a property visible in the text. Load-bearing is not a property visible in the text. It lives in a conversation held two years ago between people who have moved on, and a marker with a removal condition is the only form in which that conversation is present at the moment of decision, which is the same problem the craft has everywhere else and the same answer. Move the context to where the decision is made. The cost is one sentence written while you still remember why, and what it buys is that your reasoning gets to defend itself, in your absence, against arguments you will never hear.