Skip to content
Ramesh Adhikari

03 — The system

A template hands yousomeone else's answer.

A framework gives you the question that produces yours.

This chapter exists to replace one belief: “Frameworks are templates.” becomes “Frameworks are reusable thinking.”.
You arrive
Frameworks are templates.
You leave
Frameworks are reusable thinking.

How to read these

Each is four questions. Longer than that and it dies in the first loud meeting.

None will tell you what to do. Each will name what you are actually deciding — usually not the thing on the agenda.

01 — Framework

The Door Test

How much deliberation does this decision deserve?

Price the reversal before you price the work.

  1. Name the reversal.

    Write the literal sentence: “To undo this, we would have to ___.” If you cannot finish it, you do not yet understand the decision — and that, not the decision, is the thing to fix today.

    Step 1 of 4.

  2. Price it in days.

    Not in feelings. A reversal that costs a week is a door you can walk back through. One that costs a quarter is a door that welds shut, no matter how casual the meeting felt.

    Step 2 of 4.

  3. Match the process to the price.

    Cheap reversal: decide in the room, today, with one person accountable. Expensive reversal: one written page, two readers whose job is to disagree, and a date on it.

    Step 3 of 4.

  4. Write the expiry condition.

    Every decision rests on an assumption. Name the one which, if it changed, would make you reopen this — then you will notice when it does, instead of discovering it in an incident.

    Step 4 of 4.

What you end up holding

A dated page that tells the next person why, not just what — and names the condition under which they are allowed to change it.

Where it breaks

It breaks when the cost of reversal is genuinely unknowable — a new market, an unproven technology, a regulator who hasn't ruled yet. Then the framework changes shape: buy information first, decide second, and treat the information purchase as the actual decision.

02 — Framework

The Complexity Ledger

Where did the complexity actually go?

Every simplification is a transfer. Name the recipient.

  1. State the credit.

    “This makes X simpler.” Good — that half is usually said loudly and often in a slide. Write it down anyway, because it is the claim you are about to test.

    Step 1 of 4.

  2. Find the debit.

    Complexity is conserved. It moved to exactly one of four places: the code, the operations, the product surface, or the user's head. Pick one. “Nowhere” is not an available answer.

    Step 2 of 4.

  3. Name the payer.

    Not a team — a person, in a situation. “The on-call engineer at 3am.” “The finance lead during month-end close.” Abstractions cannot object; people can.

    Step 3 of 4.

  4. Check whether they consented.

    If the payer was not in the room, you did not simplify anything. You moved a cost onto someone who had no standing to refuse it, and you will meet that cost again later wearing a different name.

    Step 4 of 4.

What you end up holding

One line in a ledger you keep: “Simpler for ___, at the cost of ___, paid by ___.” Six months of those lines is the most honest architecture document a team can own.

Where it breaks

It breaks when the payer is a future hire who does not exist yet. Then the ledger needs a proxy — a named person whose explicit job in the room is to argue on behalf of people who aren't there.

03 — Framework

Constraint-First Design

What is actually fixed?

Design from what cannot move, not from what you wish were true.

  1. List everything that cannot change.

    Money, date, headcount, regulation, an integration you do not control, a contract already signed. Write them as sentences, not as bullet fragments — vagueness is where fictional plans hide.

    Step 1 of 4.

  2. Challenge exactly one.

    Most constraints are conventions wearing a constraint's clothes. Pick the single one whose removal would change the most, and go find out if it is real. One, not all — challenging everything is the same as challenging nothing.

    Step 2 of 4.

  3. Design from what survives.

    The remaining constraints are not context surrounding the problem statement. They are the problem statement. A design that would also work under different constraints has not been designed for these.

    Step 3 of 4.

  4. Name what you are deliberately not building.

    A scope that has excluded nothing has decided nothing. The exclusion list is the artefact that survives the meeting; the inclusion list is the one that quietly grows.

    Step 4 of 4.

What you end up holding

A scope with an explicit “not doing” list that someone senior has put their name against.

Where it breaks

It breaks when the constraints are mutually contradictory — date, scope and quality all declared fixed by different people. Then this framework's output is not a design. It is an escalation, and delivering it as one is the work.

04 — Framework

The Second Reader

Will this survive the person who inherits it?

The first unanswered question is the defect.

  1. Pick a real stranger.

    Not “a junior developer” — an actual named person, or yourself in six months with none of today's memory. Abstract readers are infinitely forgiving, which makes them useless.

    Step 1 of 4.

  2. Give them only the artefact.

    The code, the document, the dashboard. No conversation, no thread, no you. If your system requires you to be reachable, you are not a maintainer — you are a dependency.

    Step 2 of 4.

  3. Find the first question they must ask a human.

    That question is the defect. Not the code around it, not the missing test — the fact that the artefact could not answer for itself.

    Step 3 of 4.

  4. Answer it inside the artefact, then repeat.

    Stop when the first remaining question is one you would genuinely be happy to be woken up for. That is the finish line, and it is a much lower bar than “documented” — which is why it gets cleared.

    Step 4 of 4.

What you end up holding

An artefact whose first unanswered question is worth asking — and a much shorter onboarding.

Where it breaks

It breaks on genuinely novel work, where nobody could hold the context yet. There the goal shifts: not “no questions”, but “the questions people arrive with are the right ones”.

Notice what none of these produce: a diagram, a stack, an estimate.

They produce a sentence someone can fight.

Aframeworkyoucan'texplaininonesentenceisapreferencewearingacostume.

Systems aren't invented.

They're survived.

Here's what surviving them taught me.

→ContinueChapter 04 · About