Four Answers to One Question

The tournament pointed to the wrong sport, and I had just watched its link disappear after it was added.

This was supposed to be ordinary work. A tournament belongs to a sport. Connect the two, and the connection should stay there. Instead, the result changed depending on which part of the feature someone used. Sometimes the link vanished. Sometimes it pointed somewhere it should not. Sometimes the system refused to make the connection because it said one already existed.

That last answer was especially maddening. A link could appear to be there, yet another part of the same feature would insist it was not. Or the system could say the link already existed when the place that ought to remove it could not find it. Nothing about that feels trustworthy when you are the person trying to use the feature.

At first, I treated the strange results as separate problems. I read the instructions behind the tournament page. Then I read the part that makes a link, the part that removes one, and the part that checks for a duplicate. Each little piece looked sensible when I looked at it alone. That did not get us anywhere. It cost an afternoon, plus the particular kind of patience that disappears when a simple task changes its story every time you try it.

The real question was much smaller: what name should this tournament use when the system needs to find it again?

There were two possible answers. Most of the time, the tournament used a username. In some cases, when there was an organization name, it was supposed to use that instead. The trouble was not that anyone had written a wildly wrong rule. The trouble was that the rule had been copied into four different places.

One place used the full rule. It chose the organization name when that was appropriate, otherwise the username. Another place used only the username. The other two had their own versions. All four were trying to answer the same question, but they were not guaranteed to give the same answer.

A resolver is the technical name for a small named rule that answers one repeated question. In plain English, it is one label maker instead of four people writing labels from memory.

That difference explains the confusing behavior. The linking step could file the tournament under the organization name. The duplicate check could look only under the username and decide there was nothing there. The removal step could look in the wrong place too. Each step could be doing exactly what its own instructions said, while the whole feature was still wrong.

I finally saw the shape of the problem in the change itself. Four nearly identical lines of instructions had to change at once. Their outer shape matched, but each had a slightly different way of choosing the tournament’s identity. It was like finding four handwritten notes about where the spare house key lives. Each note sounds believable. One says under the flowerpot, one says by the back door, and one says the key is already gone. The problem is not a bad note. The problem is that there are four notes.

The repair was pleasantly boring. The choice moved into one small named place. It applied the organization name or username rule once, and every part of the feature used that same answer. The page lookup, the link, the removal, and the duplicate check all stopped making up their own version of the rule.

After that, the four paths could not quietly disagree about where the tournament belonged. If the rule ever needs to change, there is one place to change it. If the rule is wrong, it will be wrong in one visible place, not in one hidden corner out of four. That is much easier to find, explain, and repair.

I used to think repeated instructions were mainly a future housekeeping problem. Four copies mean four things to remember when something changes. That is true, but it is not the whole problem. When the repeated instruction answers a question like “Which one is this?” or “Does this already exist?”, the copies are competing answers in the present. The feature is not merely harder to maintain. It is already capable of contradicting itself.

This does not mean every repeated sentence needs a grand new system around it. A grocery list can say “milk” twice without causing harm. The warning sign is more specific. Watch for a value that gets worked out in more than one place, especially when different actions all depend on it. Creating a record, finding it, removing it, and checking whether it exists should not each be allowed to decide what “it” means.

On Monday, pick one process at work or at home that has a name, number, or status written down in several places. It might be a customer number on a form, a price in two spreadsheets, or a label used by more than one step. Ask one plain question: who gets to give this thing its name? If the answer is “several places, depending on what you are doing,” you have found something worth fixing before it starts arguing with itself.

dxdev LESSON · paste into your AI coding agent
LESSON: The same identity rule copied into four call sites is four separate answers waiting to disagree
SOURCE: dxdev.com/blog/2026-02-26_four-answers-to-one-question
WHAT HAPPENED: A tournament's identity key was supposed to follow one rule: use the organization name if one exists, otherwise the username. That rule was implemented independently in four places (the page lookup, the code that creates a link, the code that removes one, and the duplicate-existence check), and the four copies did not agree closely enough. The linking step could file a tournament under its organization name while the duplicate check only looked under the username, so the system could report a link missing that actually existed, or refuse to create one it claimed already existed. The fix moved the rule into a single resolver function that all four call sites use, so there is exactly one place that decides a tournament's identity.
THE RULE: When more than one code path independently computes the answer to the same identity question (which value names this record), collapsing them into one shared resolver is what prevents those paths from silently disagreeing about what the record even is.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any identity- or key-selection logic (which field or fallback value identifies a record) duplicated across a create path, a read/lookup path, an update path, and a delete-or-exists-check path.
  2. Any two or more near-identical conditionals, in different files, that compute the same derived value with a slightly different fallback order or condition.
  3. Any bug report where two parts of the same feature disagree about whether something exists, which is a strong sign of two independent identity resolutions rather than one shared one.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.