Comparisons

Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.

Goal vs implementation Functional vs non-functional requirements Assumption vs requirement MVP vs bad prototype Prototype vs spike Vertical slice vs horizontal layer Essential vs accidental complexity Reversible vs irreversible decisions Dependency-first vs value-first ordering Documentation vs tutorial Known vs unknown vs assumed Decomposition by capability vs by layer Happy path vs failure path Build vs buy Deterministic workflow vs agent Source of truth vs snapshot Problem framing vs requirements Walking skeleton vs MVP Thought experiment vs experiment

Goal vs implementation

What people get wrong about this pair

Requests arrive as implementations — "add a Redis cache to the product page", "build a dashboard", "we need a queue" — and get built as asked, so the team delivers the implementation and nobody checks whether the goal moved. The requester is not wrong to phrase it that way; they are describing the only solution they can picture. The cost is that the goal is never written down, so it cannot be tested against, and a cheaper solution — an index instead of a cache, a weekly email instead of a dashboard — is never on the table. The strongest form of the other side is that an experienced requester often has good reasons for the implementation they named, and treating every request as a framing exercise is condescending and slow; the honest move is to ask for the goal in one sentence and then take the named implementation seriously as the first candidate.

Goal — what would be different for the requester if this existed

Use it when

At the start of every request, and again whenever a ticket arrives already naming a technology. The goal is the thing you can check the finished work against.

Implementation — a particular way of making that difference

Use it when

Once the goal is written and the constraints are known — then implementations can be compared, and one chosen, against the goal.

Aspect	Goal — what would be different for the requester if this existed	Implementation — a particular way of making that difference
How it is phrased	"Product pages should load fast enough that people do not leave"	"Add a Redis cache to the product page"
Can be checked against	A measurement of the outcome	Whether the thing exists
Number of solutions	Several, to be compared	One, already chosen
Who supplies it	The person with the problem	Often the same person, describing the only solution they can picture
When it is known	Before any design	After the goal and the constraints
Typical mistake	Goal so vague it cannot be missed — "make it better"	Built exactly as asked; goal untouched

Take it further

You are stuck because X → do Y →

The searchable index of the domain.

Technology Decision Tool →

Which problem are you solving? Then the tool.

Trade-Off Thinking →

Every comparison is a trade-off with the axes named.