The Design Payoff Line, and Debt That Is Not Debt

Overview

Two ideas that do most of the practical work in a debt assessment. The first tells you when a shortcut stops being a shortcut. The second tells you which items on your list do not belong there at all.

Both are uncomfortable to apply honestly, which is why they are worth having.

The design payoff line

The claim behind every deliberate shortcut is that skipping design work makes delivery faster. That is true, and it is true only up to a point.

The curve and the term are Martin Fowler’s, from his Design Stamina Hypothesis — the companion piece to the quadrant in the previous topic.

Early on, a system with little internal structure genuinely ships features faster than one with careful boundaries — there is less to understand, less to keep consistent, and nothing to refactor. The design investment has not paid off yet.

Past a certain accumulated size and change rate, the curves cross. The structured system keeps delivering at roughly a constant rate while the unstructured one slows down, because every change now requires understanding more and risks breaking more. That crossing is the design payoff line, and the important property is what happens after it:

Past the payoff line, the shortcut is no longer buying speed. It is only producing cost.

This reframes the decision usefully. The question about a shortcut is never “is this bad practice?” — it is “where is this part of the system relative to its payoff line?” Before the line, taking the shortcut is correct and refusing it is premature engineering. After the line, continuing to take it is not a trade at all, because there is no longer anything on the other side of it.

graph LR
  A["<b>Before the line</b><br/>skipping design<br/><i>genuinely faster</i>"] --> B["<b>The crossing</b><br/>curves meet"]
  B --> C["<b>After the line</b><br/>the shortcut buys<br/><i>nothing at all</i>"]

  classDef pre fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef at fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef post fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A pre
  class B at
  class C post

Three regions. The mistake in both directions is assuming your part of the system is in a different one than it is.

The line is per-area, not per-system. One part of a codebase can be well before its payoff line while another is far past it, and a blanket statement about the whole system is therefore always wrong in one direction or the other.

Debt versus badly done work

The distinction that matters most, and the one that creates friction.

Mess in the code is not debt. It is badly done work — and calling it debt is how teams launder poor quality.

The distinction is Robert C. Martin’s, who put it bluntly: a mess is not a technical debt. Debt is a decision; a mess is just a mess.

The difference is whether anything was bought. Debt is a trade: acceleration now, cost later, with both sides at least roughly understood. If nothing was gained — no deadline met, no learning acquired, no decision made — then there was no trade and the word does not apply.

The laundering is what the vocabulary does. “Technical debt” sounds deliberate, strategic, even sophisticated: a conscious financial instrument. Applied to code that is simply poor, it converts an unflattering fact into a respectable one, and in doing so it removes any reason to change how the work is done. A team that calls all of its mess debt has no vocabulary left for the thing it needs to fix.

Why insisting on this is worth the friction: the two have different responses. Debt is repaid, scheduled against other work, and sometimes deliberately carried forever. Badly done work is prevented — through review, standards, or capability — and repaying instances of it without changing the process means producing more of it in parallel.

Saying it without an accusation

This is where Module 8 and Module 8 become necessary rather than adjacent. “This was done badly” is a statement about colleagues, usually unfair given the constraints they worked under, and expensive in exactly the currency you cannot spare.

Three framings that preserve the distinction without the cost:

• About the artifact, not the author: “this area has no recorded trade behind it”, rather than “this was done carelessly”.
• About the present, not the past: “whatever the original reasoning, nothing is being bought by it now” — which is the payoff-line argument and needs no history at all.
• Separate the instance from the process: repairing one case is a ticket; reducing the rate is a conversation with engineering leadership, and conflating them makes both harder.

One payoff line, and one item that leaves the list

Two honest calls, and the second is the one the rubric asks for.

The payoff line on the 4 TB shared database. Built as one PostgreSQL store in 2016, which was correct — a single database with no service boundaries ships features far faster at that stage, and the company reached $48M in recurring revenue partly because of decisions like it.

Where is it now? The answer differs by area, which is the whole point of the per-area rule. For the twenty extracted Go services, the shared store is past the payoff line: each needs careful coordination around a schema it does not own, and the entanglement is exactly what makes the remaining 65% of the migration slow. For the monolith’s own untouched modules, it is still before the line — those areas change rarely, and imposing boundaries on them now would be cost with no return.

So the correct statement is not “the database is debt”. It is: past the payoff line where the migration is active, before it where the monolith is quiet — and that sentence is directly actionable, because it says repay along the migration’s path and nowhere else.

The item that leaves the list. The 2023 routing code, still present behind a disabled flag.

Classified honestly, it is not debt in any of the four cells. Nothing was bought — the feature was switched off, so no acceleration was retained. No trade was recorded. Nobody decided to leave the code; the project ended and attention moved. It is abandoned work left in place, which is a different thing and takes a different response: delete it.

It also now costs something it did not cost in 2023. Module 9’s work on documentation as context established that stale material reachable by an agent becomes a source of confidently wrong answers — and dead code paths behind a disabled flag read to a model exactly like live ones, with design notes to match.

And the framing that makes it sayable. Not “the 2023 work was done badly” — Module 8 established that the quiet switch-off is organisational scar tissue, that Ivan Petrov’s concern is a repeat of it, and that the episode is the most delicate subject in the company. The framing is present-tense and about the artifact: this code is unreachable, it is misleading to both engineers and agents, and removing it is a small cleanup with a clear benefit. No history, no author, no verdict on 2023 — and the deletion gets done.

Feeds the workbook

Two rubric items land here: the design payoff line applied to a specific decision, and at least one item honestly reclassified as poor quality or abandoned work rather than debt. Write the framing you would actually use, not just the classification.

Check your understanding

1. Pick an area of a system you know. Is it before or after its payoff line, and what evidence would settle it?
2. Find something called debt that bought nothing. What is it actually, and what response does that imply?
3. Write the sentence you would say in a review about badly done work, with no accusation in it.

---

→ That closes the reading of the situation. Now the three ways to change it. — Refactor, rewrite, or strangle