A Naming Defect With a Twenty-Day Fuse

The field is called Manager_Approve_Max_Pct__c. It stores £32.

Not 32 percent. Thirty-two pounds.

The Finding Nobody Wanted

I raised it as a naming defect at the Lowest priority available. A Custom Metadata field whose name says percentage and whose value is an absolute currency ceiling.

It came back rejected, with a reason I understood: don't raise metadata the user never sees or touches.

That is a defensible line. Nobody in the business will ever open that record. There is no screen where a wrong percentage sign confuses an agent. The configuration is set once by a developer who knows exactly what the number means. Judged on who could misconfigure the system, the finding scores close to zero, and the rejection is correct.

I let it go. Lowest priority, rejected, move on.

Twenty Days Later

A tester in SIT opened a discount scenario on a £57.00 product and applied a discount of £18.90.

Then they went looking for the rule that decides whether that needs manager approval. They found the ceiling. They read the field name.

Max_Pct — a maximum percentage. The configured value is 32.

So they did the arithmetic the name told them to do. £18.90 against £57.00 is 33.16%. Thirty-three point one six is more than thirty-two. The discount should have gone for manager approval and it did not.

They raised it at the Highest priority. Approval governance, money, a rule apparently not being applied.

The story bounced out of a forward status. A developer was assigned. Time was spent investigating behaviour that was completely correct — £18.90 is a long way under a £32 ceiling, and the system auto-approved it exactly as designed.

The Real Damage Path

The rejection asked one question: who can misconfigure this?

Answer: nobody the user can see. And that answer is true.

It is also the wrong question, because misconfiguration was never the failure mode. The failure mode is reading.

Every internal name is consumed by somebody who then derives an expected result from it. A tester deciding what should happen. A BA writing acceptance criteria. A developer arriving in eight months who needs to know what the ceiling means before touching the resolver. None of them appear in the "user" category the rejection used, and all of them are end users of a field name.

That is the mechanism. A name that lies does not corrupt data. It corrupts expectations, silently, in everyone downstream who has no reason to doubt it.

What This Was Not

It would be comfortable to file this as a boundary problem. It is not, and the numbers rule it out.

£18.90 sits nowhere near the £32 boundary. It is not on the limit, not one penny either side, not in any neighbourhood a boundary technique would visit. It is not near 32% of £57.00 either.

It sits in the gap between the two readings — low enough to be safely inside the pounds interpretation, high enough to be outside the percentage one. That gap is created purely by the ambiguity of the name. There is no range analysis that produces it, because the defect was never in the range.

The defect was in the vocabulary.

No amount of boundary-value testing catches a case whose expected result is wrong. Boundary analysis assumes you already agree on what the rule is and you are probing where it flips. Here two competent people disagreed about what the rule was, and every technique that starts after that agreement was useless.

What I Take From It

Add up what the Lowest-priority finding actually cost once it was rejected: a Highest-priority false defect, a story pulled backwards through the workflow, a developer investigating correct behaviour, and a sprint defect picture showing an approval failure that did not exist.

A naming defect is not cosmetic debt waiting for a quiet week. It is a latent false-defect generator, and the fuse length is however long it takes for the next person to read the name and act on it. Here it was twenty days.

So the priority argument I now make is about arrival time, not aesthetics. When a name and its value disagree, the question is not "who could break the system with this" but "who will read this and be confidently wrong" — and the answer is everyone who arrives after the person who named it.

If renaming is genuinely too expensive, the fallback costs nothing: put the unit in the description on the record itself, where the next reader is already looking.

Which field in your system has a name that would give a new tester the wrong expected result — and how long has that fuse been burning?