Fail Loudly At The Boundary Rather Than Quietly In The Middle

The best place to detect wrongness is where it enters, not where it eventually causes damage.

When something wrong enters a system and is not challenged, it travels. It is stored, copied, aggregated, used in decisions, and passed onward, and by the time it produces a visible failure it may be far away from where it entered and mixed with correct data that is now equally suspect. The cost of detection rises steeply with distance. Caught at the edge, a bad input is a rejection and a clear message. Caught six steps in, it is an investigation. Caught after it has been persisted and reported on, it is a data cleanup, and cleanups are where teams lose weeks.

The practice is to be strict at the boundary and trusting inside it. Wherever information crosses into your system, from outside, from another component, from a stored source, check that it is what you expect, and refuse it clearly and immediately if it is not. Having done that, the interior can rely on its assumptions and stay simple. The alternative, defensive checking scattered everywhere, is worse in both directions: it clutters the logic and it still misses cases, because a check without a defined boundary has no principled place to live and no way of being complete.

The instinct that fights this is the wish to be helpful. It feels accommodating to accept something slightly malformed, substitute a sensible default, and continue. Occasionally that is right, when the operation is genuinely optional and continuing is better than stopping. Usually it is not. Continuing with a guess converts a clear, immediate, cheap failure into a silent wrong answer that surfaces later without a trace of where it came from. Silence is the expensive option. A system that stops and says plainly what it did not understand is easier to live with than one that keeps going and quietly invents.