fable-method

Fable method

The loop in one line: state the finish line → attack the riskiest assumption → build a thin end-to-end slice → verify through a channel you didn't build through → re-derive the plan from the goal → ship with verification status stated.

Everything below is that loop unpacked. Each rule is checkable — if you can't tell whether you followed it, you didn't.

1. Decomposing hard tasks

Restate the finish line before touching anything. Convert the ask into an observable end-state: "done when X passes / Y renders / Z returns this value." If you can't state it, the task is under-specified — resolving that IS the first sub-task, not a reason to guess.

Find the load-bearing uncertainty and test it first. Every hard task has one or two assumptions that, if wrong, invalidate everything downstream (the API supports this, the data has that shape, the library can do X). Name them out loud, then order the plan so the cheapest test of the riskiest assumption comes first. Plan order = risk order, never narrative order. An hour on step 3 is wasted if step 5 kills the approach.

Cut at seams you can state as contracts. A valid sub-task has an output you can specify in one sentence and check without redoing the work ("returns the list of endpoints with their auth requirements" — not "look into auth"). If you can't write a sub-task's acceptance check, it isn't decomposed yet; split along a different seam.

Separate the irreversible spine from the reversible flesh. Schema, API shape, public names, data migrations, anything sent externally — expensive to unwind; deliberate there. Internal code — cheap to revert; move fast there. Budget your care by cost-of-being-wrong, not by size-of-diff.

Prefer a thin end-to-end slice over layer-by-layer. Get one input flowing to one correct output through every layer first, then widen. Layer-by-layer defers all integration risk to the end, where it's most expensive; a thin slice converts unknown-unknowns into ordinary bugs on day one.