The Diagram Was Never the Deliverable

A chief executive says: “Customers should get their refunds within two minutes.”

By the time that sentence reaches a developer, it has become RefundService.ProcessAsync().

Somewhere between those two lines, intent was translated into implementation — and translation is never free. Information is lost. Assumptions creep in. Constraints appear that no one signed off on. Trade-offs get made quietly, by people who never heard the original sentence and had no way to know which parts of it were sacred.

None of this requires incompetence. It happens through a hundred small, reasonable hand-offs, each shaving a sliver of intent off the edge. Add the slivers up and you get the outcome everyone has seen at least once: a system that is technically flawless and no longer solves the problem anyone actually had.

This is why the diagram is such a seductive trap. It looks like the deliverable. It is tidy, it is reviewable, it fits on a slide. So we treat producing it as the job, and treat the review that approves it as the finish line.

But the diagram is not the output of architecture. It is evidence. The real deliverable is harder to draw: confidence — that we are solving the right problem, that we understand the risks, that we have weighed the alternatives honestly, and that the room is genuinely aligned rather than merely quiet.

You can feel the difference in a review. A diagram-led review asks, “Is the design correct?” A confidence-led review asks, “Are we still solving the original problem, and does everyone here believe it?” The first can pass while the project quietly fails. The second is the one that protects the intent all the way down to the code.

The job, then, is not to draw the picture. It is to keep asking, at every hand-off, whether the original sentence is still intact. The picture is just the artefact you leave behind while doing it.

The full argument — how intent degrades, and what it takes to preserve it — runs through the books.