# Worth before work > Before any work starts, one gate decides whether it starts at all. Page: Methodology · Plan Canonical: https://banes-lab.com/disciplined-methodology/plan#worth-before-work This section is stop 21 of 102 in the learning route. Previous: [06 - Well-formedness](https://banes-lab.com/pag/guide/well-formedness.md). Next: [13 - The plan is a graph](https://banes-lab.com/disciplined-methodology/plan/the-flat-checklist.md). It builds on [01 - The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md). Before any work starts, one gate decides whether it starts at all. It asks three questions, as shown in [A1·a the worth gate](https://banes-lab.com/disciplined-methodology/plan#worth-before-work-panel-a): what the work is for, what finished looks like, and whether this is the most worthwhile of the approaches that are allowed. This gate is the [intent](https://banes-lab.com/records/stage/intent.md) node of [the loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md), and on the ontology page it rests on four records: an [objective](https://banes-lab.com/records/reason/node-tel-objective.md), a [utility](https://banes-lab.com/records/reason/node-tel-utility.md), a [cost](https://banes-lab.com/records/reason/node-tel-cost.md) and a [priority](https://banes-lab.com/records/reason/node-tel-priority.md). A task that cannot answer these questions is not ready to be a task. ### What is this for Work that skips the question of worth can be done well and still turn out to be unnecessary. Three days into a refactor, the question of whether the refactor was needed comes up for the first time. Starting is cheaper than deciding, and a model tends to start as soon as you let it. For this reason worth is decided before any work begins, and what the work will not do is stated as plainly as what it will. The approaches that are allowed are ranked before any effort is spent, rather than the first workable one being taken. In practice, the objective is written in one sentence before the first step, worded so the result can be checked against it. What is out of scope is written beside it, because scope that is never stated grows quietly. Each approach is weighed by what it achieves against what it costs, the reason the chosen one won is written down, and only then does planning begin. To check this, read the objective again once the work is done. The result should be the thing the sentence named; a result that needs a new sentence to describe it answered a different question. Worth is not computed anywhere in this method: no tool weighs utility against cost across the approaches for you. The gate is a judgement I make and write down, and saying so openly is what stops it from being mistaken for a mechanism. The gate has a particular shape, and the shape is what makes it hold. The intent node produces an objective and a ranking, never a simple yes. A ranking needs more than one option, so a plan with only one option has not ranked anything and has not passed the gate. Each option records what it achieves and what it costs, and the chosen one is the option where that difference is largest among those that are allowed at all. An option that would cross a hard limit is not a worse option; it is not an option. Whether a change is allowed is asked again at the [constrain](https://banes-lab.com/records/stage/constrain.md) node once the work exists, because a plan that looked acceptable on paper can still produce a change that is not. [When rules collide](https://banes-lab.com/disciplined-methodology/plan/when-rules-collide.md) applies the same gate to two rules that meet on one piece of code. Stating what the work will not do often matters more than stating what it will. The stated scope of a unit is what its author intended, and its unstated scope is whatever collects around it because nothing ruled it out; the ontology calls that [speculative generality](https://banes-lab.com/records/arch/speculative-generality.md). Writing down the nearest thing the change will not do is what lets the next reader turn down the addition that would have made a focused unit into a [god object](https://banes-lab.com/records/arch/god-object.md). The same test applies to every surface, record or field a plan proposes: it has to name something that would break without it, not merely something that would read it, and an addition that breaks nothing either way is the problem. The same task reads differently once worth has been decided. Without it: *clean up the config and the checker, they have gotten messy*. With it: *objective, one limit with [one home](https://banes-lab.com/disciplined-methodology/build/one-home.md); not in scope, the checker's other options; chosen, derive it from the config, because the two other homes cannot be deleted otherwise*. The second version can be finished. The first cannot. A1·a the worth gate ```mermaid flowchart TB request["A request"] objective["The objective · one sentence the result is checked against"] nongoal["The non-goal · the nearest thing this will not do"] branches["The allowed approaches"] rank{"Highest worth · utility minus cost?"} chosen["The chosen approach, and why the others lost"] stop["Below worth · redirect or stop"] request --> objective --> nongoal --> branches --> rank rank -- yes --> chosen rank -- no --> stop ``` ## Links to - [Intent](https://banes-lab.com/records/stage/intent.md) - [The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md) - [Tel Objective](https://banes-lab.com/records/reason/node-tel-objective.md) - [Tel Utility](https://banes-lab.com/records/reason/node-tel-utility.md) - [Tel Cost](https://banes-lab.com/records/reason/node-tel-cost.md) - [Tel Priority](https://banes-lab.com/records/reason/node-tel-priority.md) - [Constrain](https://banes-lab.com/records/stage/constrain.md) - [When rules collide](https://banes-lab.com/disciplined-methodology/plan/when-rules-collide.md) - [Speculative Generality](https://banes-lab.com/records/arch/speculative-generality.md) - [God Object](https://banes-lab.com/records/arch/god-object.md) - [One home](https://banes-lab.com/disciplined-methodology/build/one-home.md) ## Linked from - [PAG and the method](https://banes-lab.com/pag/introduction/pag-and-the-method.md) - [From intent to structure](https://banes-lab.com/pag/patterns/intent-to-structure.md) - [Execute the template](https://banes-lab.com/disciplined-methodology/plan/execute-the-template.md) - [Ask where it appears](https://banes-lab.com/disciplined-methodology/plan/ask-where-it-appears.md)