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.
Decomposition by capability vs by layer
By-layer is offered as a decomposition because it is true of every web application, and that is exactly why it says nothing about this one: the tree "Frontend / Backend / Database" cannot be traced by a customer's workflow, has no leaf that can be demonstrated alone, and puts every hard question — who owns cart state, what happens when payment fails — nowhere. The cost is a plan that cannot be reordered by value or risk because its pieces are not features. The strongest form of the layer side is organisational: teams and skills really are layered, and someone has to own the database; the reply is that ownership is a structure question, and the plan is a capability question, and confusing them is how a team ships three complete layers and no checkout.
For the plan: each capability can be built, tested and demonstrated on its own, and the core workflow traces through them.
For the structure inside a capability, and for organising a team that owns a layer. Never as the plan.
| Aspect | By capability — catalog, cart, checkout, orders, payments, admin: what a user of the system can do | By layer — frontend, backend, database: where code lives |
|---|---|---|
| Leaves | "Create the order", "take payment" | "The backend" |
| Testable leaf | Yes — an observation per leaf | No — a layer has no single test |
| Traceable by the core workflow | Yes | No |
| Can be reordered by risk and value | Yes | No — every layer is needed by everything |
| Right use | The plan | Code organisation and team ownership |
| Sign of the mistake | Capabilities so fine they are functions | A decomposition that fits every product |