The name is doing something the sentence cannot. “Use case” names a method, one with a literature, templates, worked examples and a clear account of what a finished use case contains. A line on a slide borrows the standing of that method whether or not any of the method’s work was ever done. The same is true one level down, in the backlog, where a single sentence called a user story borrows the standing of a different method with the same indifference to whether its work happened.

It would be easy to call this carelessness, and it would be wrong. Both forms were designed to be short, and both were designed to be read by people making decisions. What they were not designed for is to be read on their own. Each was a placeholder whose meaning depended on a process that would complete it, and what organisations have carried forward is the placeholder without the process. The artefact has not changed. The practice it belonged to has degraded, and the unit that degraded is the practice: the artefact together with the process that finished it.

What the word promises

Alistair Cockburn’s Writing Effective Use Cases, the standard text on the form, is candid that the term covers a wide range. A use case can be a name. It can be a brief of a few sentences, a casual narrative of a paragraph or two, or a fully dressed document with stakeholders, preconditions, guarantees, a main success scenario and a numbered account of the ways it can fail. Cockburn is explicit that saying a project writes use cases tells you very little until you know which of these it writes.¹

He is equally explicit that the short end of the range is legitimate. The name alone, he says, counts as the first level of precision, and a list of names is a useful thing to have.² So the one-sentence use case on the slide is not a corruption of the form. It is one of its sanctioned states. The question is what that state was sanctioned for.

Built to be finished later

Cockburn orders the work of writing use cases in stages of rising precision: first the actors and their goals, then a brief or a main success scenario, then the conditions under which it can fail, then how the system handles each failure. Each stage costs more than the one before, and the order exists to protect that cost. “Precision is not the same as accuracy,” he writes.³ A statement can be vague and right, or exact and wrong, and effort spent making a wrong goal precise is effort thrown away. So the low-precision list comes first, is checked for accuracy, and only then earns the investment in detail. The short form is a stage, and a stage implies the next one.

Two terms help to keep this straight. Altitude is how high or low in scope a piece of work sits. Grain is how fine the resolution of attention given to it is. The two vary independently.⁴ A use case name is work at a fair altitude and at the coarsest grain there is. The staged process adds grain without changing the altitude, and the name on its own records none of that grain, only the place where it was meant to go.

User stories arrived in the late 1990s with Extreme Programming and made the same arrangement more openly. Ron Jeffries described the story card as “a token representing the requirement”, carrying just enough text to identify it and remind everyone what it is; the requirement itself travelled in conversation and was confirmed by tests.⁵ Mike Cohn, whose User Stories Applied became the standard account of the form, quotes Rachel Davies to the same effect: cards represent requirements rather than document them.⁶ Cockburn supplied the phrase that has stuck to stories since, describing the cards on an early Extreme Programming project as each “a promise for a conversation between a requirements expert and a developer”.⁷

The two forms are closer than their later reputations suggest. Cockburn’s own discussion of briefs notes that some teams never write more than briefs, keeping the rest of their requirements in continual discussion, prototypes and frequent increments.⁸ A brief backed by conversation and a story backed by conversation are the same kind of object at different altitudes. Each is built to be finished later, by people, in a process that the artefact itself does not contain.

Meant for the executive’s desk

The obvious diagnosis would be that these short forms were never meant to leave the team, and that the damage starts when they reach people who make decisions. Both authors rule that out.

Cockburn locates the first moment at which use cases create value in the list of goal names, examined by user representatives, executives, developers and project managers, who estimate cost and effort from it and negotiate what gets built first.⁹ Cohn is as direct. Rough cost and benefit, he notes, are often needed before a project receives funding and approval, and his chapter on release planning describes a manager who writes the stories, researches the market on the strength of them, and decides from their estimated cost whether the product will be built at all.¹⁰ The short form reaching the executive is designed in.

What separates the designed case from the familiar one is what surrounds the decision. In Cockburn’s process the list reaches executives as the opening of a loop: it is reviewed for accuracy, reprioritised, elaborated in stages, and corrected when the failure conditions turn up something nobody had considered. In Cohn’s, the estimates are revisited, measured velocity replaces the guessed one within a few iterations, the customer stays with the team throughout, and the plan built on the first estimates comes with an explicit warning not to trust it too far.¹¹ The decision made on one-liners is provisional because the process around it keeps it provisional.

On the deck, the same decision closes the loop instead of opening it. The allocation is made, the line becomes a commitment, and nothing downstream is organised to test whether the line was accurate. The one-liner has not changed. What it is being used for has, and it is being used for something it was never fit to carry.

Precision without accuracy

Cohn makes an argument about sparseness that is easy to read past. A story card annotated with every detail its author could think of, he observes, invites readers to mistake extra detail for extra precision.¹² A sparse card does the opposite. Two developers discussing a story that says only that a company can pay for a job posting by credit card will not forget that their discussion is abstract; too many particulars are missing for anyone to treat it as settled. In his account the thinness of the card is a feature. It tells the people holding it that the work is not done. He makes the same point about the medium: the low-tech nature of an index card is a constant reminder that stories are imprecise, and the same text held in software starts to look like a formal requirement.¹³

That signal only works for readers who know what the card is. Inside the team, a one-line story reads as not yet worked out, because everyone present knows the conversation is still to come. Move the same line onto a slide in front of people who were never part of that process, and its brevity reads the other way. A single clear sentence looks decided. It looks like the output of thought rather than the prompt for it. The one-liner does not merely lose its backing when it leaves the process. It misrepresents its own status. A slide can show how precise a statement is. It has no way to show how accurate it is, and accuracy was the property the process existed to establish.

Organisations do eventually notice that sparse items are not enough. The usual correction, in practice, is to add content to the item: acceptance criteria, attached documents, longer descriptions, templates with more fields. What is rarely restored is the conversation, and least often the part of it that included the engineers who would build the thing. Requesters, for their part, tend to be reluctant to join a process that asks for their time beyond writing the request. This is a practitioner’s observation, not a measured result, but the effect of the correction follows from Cohn’s own argument. Detail added without the conversation raises precision without testing accuracy, and it produces the misreading he warned of: the belief that the card now holds everything, and that nothing further needs discussing.¹⁴ The inversion no longer stops at the edge of the team. The people closest to the work now read the item the way the audience of the deck did.

The engineers mattered for a specific reason. Cockburn places the second moment of value in use case writing at the point where the writers brainstorm the ways a scenario can fail, because that is where unconsidered stakeholders and missing business rules surface, often sending business experts off to settle what the system should do.¹⁵ That discovery happens when someone who knows the system confronts someone who knows the intent. Cohn opens his book on the same point: requirements are a communication problem between two sides, and if either side dominates, the project loses.¹⁶ Detail written by one side alone is that dominance in document form.

The same route twice

Two forms travelling the same route could be a coincidence. These are not, because they sit at different altitudes of the same planning structure. Cohn is clear that a use case almost always covers a much larger scope than a story, and that a story resembles a single scenario within one.¹⁷ Cockburn uses use case titles as the unit of release planning, and discusses use cases whose delivery is spread across several releases.¹⁸ In the work-item hierarchies that organisations build around these methods, the use case, or its successor under another name, usually sits above the story. Each altitude acquired its own short form, and each short form lost its completing process in the same way.

The routes differ in one respect. At the altitude of the use case, the one-liner leaves the process entirely. It travels upward into portfolios and decks, far from anyone who would elaborate it. At the altitude of the story, the process stays within reach. The team that would hold the conversation is still there, and what happens instead is the correction already described, where text is added in place of a conversation that remains available and goes unheld. The mechanism is the same at both altitudes: an artefact circulates further than the process that completed it, and is then read as though it were complete. A backlog tool can sit as far from the conversation as a board slide does.

This is also why the problem cannot be put down to executives misreading slides. It appears wherever the artefact outruns its process, including places where nobody senior is looking.

Cohn’s book contains a small instance of the move, told as a success. Preparing to close a deal with a much larger company, his team was asked for a copy of the requirements. They took their stories out of the system that held them, pasted them into a Word document, and added a cover page and a signature page, after which, in his words, everyone was happy.¹⁹ It was a sensible thing to do in the circumstances, and nothing in the account suggests harm followed. It is worth noticing for what it shows: a set of placeholders, each designed to be finished later, turned into a signed statement of what would be built by changing nothing except the container.

Nor were the forms themselves at fault. Cockburn published the standard account of the fully dressed use case, and in the same book the phrase that marks a story as a promise of a conversation. He held both forms at once, and was clear about which job each was for. The distinction he kept is the one that organisations dropped.

What the reader of the slide cannot know

The consequence lands on whoever reads the slide. That reader cannot tell a one-liner that compresses weeks of work from one that compresses nothing, because the cue that once distinguished them was never in the sentence. It was in the sentence’s position: where it sat in a process, who had worked on it, what stage it had reached. The deck keeps the sentence and strips the position.

It is tempting to call the resulting risk invisible. That overstates it. Anyone can ask to see the use case behind a line, and the question has an answer: either there is a set of scenarios, a record of the failure conditions considered, a trail of conversation with the people who would build it, or there is not. The difficulty is that the setting does not invite the question. A deck is built for comparison across lines, and asking what stands behind one of them breaks the comparison the deck exists to make.

Little of this is new, but one thing has changed its proportions. Writing a plausible one-line use case has always been cheap. With an AI assistant it now takes minutes to produce a dozen, each as crisp as the one that took a month to earn. The share of unbacked lines on any given page rises, and the page looks exactly as it did before.

Both forms were built to be finished later. Their surface was never meant to record whether the finishing happened, and on the slide the surface is all that is left.

¹ COCKBURN, Alistair, [2001] 2011. Writing effective use cases. 23. print. Boston: Addison-Wesley. The Agile software development series. p. 11. ISBN 978–0–201–70225–5. The passage closes a comparison of the same use case written casually and fully dressed, and argues that any process which simply says “write use cases” is incomplete.

² Ibid., p. 143. The second level of precision is the brief. The chapter treats both as working media for managing a large set of use cases.

³ Ibid., p. 17. The four stages, from actors and goals to failure handling, are set out on the same page, with the recommendation to work through them in that order.

⁴ See also “The Detail That Prevents the Detail”, which develops the two measures and names what remains when grain is stripped from work at altitude: strategy in outline, which is to say the deck.

⁵ Ron Jeffries, “Essential XP: Card, Conversation, Confirmation”, XP Magazine, 30 August 2001. The same article notes that teams new to the approach tend to reach for use cases and near-specifications, and that Jeffries has rarely found them to be what was needed.

⁶ COHN, Mike, [2004] 2009. User stories applied: for agile software development. 13. print. Boston: Addison-Wesley. Addison-Wesley signature series. p. 4. ISBN 978–0–321–20568–1. Cohn describes the card as used for planning and as a reminder, and places the substance of a story in the conversation and the tests.

⁷ COCKBURN, Writing effective use cases, p. 224. The project is Chrysler’s payroll system, whose fourteen team members sat in two adjacent rooms; Cockburn cites it as a case where excellent communication made very little writing sufficient.

⁸ Ibid., p. 38. His later chapter on briefs and Extreme Programming (p. 187) adds the condition: this works only where the people who own the requirements sit close to those who design the system, and in most projects, he notes, they do not.

⁹ Ibid., pp. 15–16.

¹⁰ COHN, User stories applied, p. 104. The funding remark is in his chapter on gathering stories (p. 45).

¹¹ Ibid., p. 106. The warning is to use the release plan to set initial expectations and to reset them continually as information arrives.

¹² Ibid., p. 19.

¹³ Ibid., p. 179. Cohn treats the choice between cards and software as open, and recommends starting with cards (pp. 180–181).

¹⁴ Ibid., pp. 19–20. His remedy is to move settled details onto the back of the card as tests, leaving the front for the story and its open questions.

¹⁵ COCKBURN, Writing effective use cases, p. 16.

¹⁶ COHN, User stories applied, p. 3.

¹⁷ Ibid., pp. 137–138. Cohn also distinguishes the two by longevity and purpose, and treats them as different kinds of thing. The reading here, that they are the same mechanism at different altitudes, is this essay’s rather than his.

¹⁸ COCKBURN, Writing effective use cases, pp. 167–170.

¹⁹ COHN, User stories applied, pp. 184–185. The anecdote appears among several reasons Cohn gives for keeping stories after they have been implemented.

Built to Be Finished Later was originally published in The Academic on Medium, where people are continuing the conversation by highlighting and responding to this story.

I proposed one such hypothesis this month.¹ Gherkin, the most common format for business-readable acceptance criteria, has no place for a guard: a condition that relates the state of a system to the parameters of the event that arrives, such as whether a cash machine can make up the requested amount from the notes it holds. The proposal, Guarded Gherkin, adds two keywords. Provided states the guard. Otherwise states what happens when it does not hold, including the frame condition that nothing else changes. Named conditions go into a glossary with a definition and an owner. The claim was modest: the format makes errors in a specification visible early, before an agent fills the gap with a guess. It also assumed a specification that is revised as findings come back. Findings came back.

They came from a test I had not planned. Afterwards, and for reasons that had nothing to do with the proposal, I built a small service with coding agents through OpenSpec, one of the spec-driven tools the proposal had been set against: about 5,200 lines of Go and some 8,000 lines of tests, built over 21 spec-driven changes. The build went well, and the service does what it should. Its record was not written in Guarded Gherkin, nor with any test of the format in mind. The two met only when I asked the format a question. Could a goal per capability, Guarded Gherkin and a glossary specify a running system, derived from its code alone?

An AI agent did the reading. It knew the proposal and the Go sources, and nothing else: not the OpenSpec record, not the design documents, not my intentions. I set the questions and the rules of method, and I questioned and decided what followed. In a second step, another agent was told how both versions had come into existence and compared the derived specification with the system’s own record. It had the sources at hand, so every contradiction it reported could be checked against the code and the archive, not merely against the other text.

What came back divides into two failures. Some decisions in the system were made by nobody. Others were made by somebody and never reached the specification. The discipline of the guard reaches the first kind. It does not touch the second.

What the other case surfaced

The reverse test produced 47 specification files in nine areas, one capability each: 256 scenarios, 97 Examples tables and a glossary of about 130 terms. Of the scenarios, 108 carry a guard. Every one of those had to say what happens otherwise, and every guard needed examples on both sides of the value that flips it.

That discipline produced 34 open questions, spread over 22 of the files. About half came directly from writing an Otherwise. A guard on a parameter, once its Otherwise has to be written, forces the question of what the system does with a value nobody expected, and the code’s answer was often a surprise. The other half came from building Examples on both sides of a guard: a value that only just satisfies it, and one that only just fails. Both are what the proposal asked of an authoring agent. Neither would have surfaced from a format that leaves the negative case and the boundary to the reader.

The questions are not all of one kind. About four are likely defects, cases where the code’s own comments describe behaviour the code does not have. One listing reports a total that counts only the entries after the paging cursor, so the total shrinks from page to page. A comment promises that an absent description can be told apart from an empty one, and the code cannot tell them apart. More of the questions concern behaviour that is consistent but surprising: an unrecognised value for a direction parameter silently means “both”, and asking a command for help ends with an error status. The rest are edge cases worth a decision. About four, as the comparison later showed, were not open at all. They had been decided on purpose, and the code gave no reason.

None of this was hidden. Each case is visible to anyone who reads the code with the right question in mind, and the format supplied the question. On the cash machine it looks like this: with one $50 note and three $20 notes, the machine can pay $90 but not $80. Provided it can make up the amount, it pays; otherwise it refuses, and nothing else changes. The Otherwise line reads like filler until someone has to write it for a guard whose failure nobody has thought about. Then it is the line that matters.

Nobody decided

The comparison answered a question the reverse test could only raise: who made these decisions? The proposal had answered it in advance. It said the unstated state is what a model fills in from its training data.

For the edge cases recorded nowhere, the answer was mostly nobody. The behaviour is the default of whatever the code hands the work to. A key of the wrong type in a document’s metadata rejects the whole document, because the YAML decoder raises a type error and the parser treats every error as unreadable input. A Windows path such as C:/notes.md counts as an external link, because the URL parser reads the drive letter as a scheme. An empty body disappears from a response, because the JSON encoder was told to drop empty fields, a convenience applied to every field alike. A file extension in capitals is accepted by one function and kept in the document's identifier by another, because two call sites made two choices.

Where an agent saw a gap, it decided, and usually wrote down why, though not in the specification. A test for links that point only to a heading within the same page carries a comment explaining that they count as dangling by design. A rule about bare directory names is argued at length in a design document. The reasons survived, in places a reader of the specification never looks. That is where the second failure begins. The silent decisions, by contrast, are the ones nobody saw. The format did not ask “and otherwise?”, so the library answered.

This corrects the proposal, though less than it seems. The gap was not filled by a judgement about the behaviour at all. It was filled by a delegation nobody examined. The agent chose the library and the data type, and training data plausibly shaped those choices. The library chose the behaviour. The decision was made at one remove, by whoever picked the tool, about a case the tool’s authors never knew would matter.

Parnas and Clements gave, as one reason for writing requirements down, keeping programmers from making requirements decisions by accident, and observed that most requirements documents leave the handling of undesired events to the programmer.² Forty years on, the undesired event has moved further down. In 1986 it fell to the person writing the code. Here it fell to a default chosen by people who never saw the system. A format that forces the other case forces someone to decide before a library does.

What the format could not hold

The verdict on the format itself is short. For behaviour, it held: nothing the system does had to be left out because the format could not express it. For the system as built, it did not, and it was never meant to. Guarded Gherkin, with its glossary, improves the semi-formal description of behaviour. That is a part of a specification, not the whole. The test measured how large the rest is.

The rest lies at two distances. The nearer one is still inside behaviour. Of the 256 scenarios, 148, or 58 per cent, carry no guard: definitions and derivations, orderings, the layout of reports and messages, timelines. Plain Gherkin carries them well. The extension adds nothing to it, and these are most of what an application is. The guard was the right gap to close. It is a smaller share of a real specification than the cash machine suggests.

The further distance lies beyond the semi-formal description of behaviour, in content that had to be bent into the format or did not fit at all. Invariants are the clearest case. “The system never writes to its input” and “the same input gives the same output” are properties of every event, not examples of one. Written as Gherkin they become “Given any state, When anything happens, Then …”, which stretches the example form past what it was made for. The cash machine has one as well: no sequence of withdrawals, refills and cancellations ever leaves it paying out a note it does not hold. No single rule states that, and every rule must respect it.

Data structures had no slot either. Which fields a response carries, and when a field is left out, turned into long chains of “And it carries …” lines that a schema would state in a few. Time and concurrency became narratives inside When steps: changes at these moments yield one reload at that moment. External standards, such as a query syntax, a markup standard or a protocol, could only be named, although anyone rebuilding the system depends on them. Rationale had nowhere to go below a sentence or two of intent per capability. The code was unusually rich in reasons, and almost none of them survived the move into the rules. The first instinct was a keyword for them, a Because line inside the rule. It was rejected. A reason is not a step, and placing it among the steps invites someone to test it as one.

Two places strained without breaking. In batch processing, such as reading every file in a folder, there are no event parameters in the usual sense, and the line between a Given and a Provided became a framing choice. It holds once the item being processed is treated as the parameter of the event. And the rule of one guard per rule turned a five-way classification into a chain of four rules, each handing over to the next in its Otherwise, linked only by names written in prose.

Build and dependency constraints never appeared at all. They are not behaviour, and the format never claimed them.

What the code could not yield

The comparison runs in both directions, and the other direction belongs to the record. OpenSpec’s specifications state their reasons inline: the 75 requirements in this system’s main specifications use “because”, “so that” or “since” 44 times, and the archived designs add whole sections of alternatives considered and rejected. The record also says what must never be added: no configurable list of paths to ignore, no query language of the system’s own, no state kept between calls. It names the intended audience and what is permanently out of scope. None of that can be recovered from code. A requirement that something must never exist looks, in the code, exactly like a feature nobody has written yet.

The cost of that blindness showed in the reverse test’s own results. About four of the 34 open questions were decisions the record had made deliberately. Broken links inside index files go unreported on purpose, because an index is not one of the documents the system checks. A bare directory name resolves to a file by design, and a design document argues why. They looked doubtful only because the code carried no reason. Reverse engineering cannot tell a deliberate decision from an accident. Rationale is what tells them apart.

Michael Nygard described the position a reader is left in. Without the reason behind a past decision, a newcomer can only accept it blindly or change it blindly.³ An agent asked to tidy up this code would have been that newcomer for those four questions, and its tidying would have been four blind changes. Parnas and Clements recorded every alternative they considered and rejected, with the reason, so that a later maintainer could find out why.⁴ This system’s record did much of that. The derived specification, for all its precision, could not, because the code it was derived from did not say.

So the comparison does not crown either side. The derived specification holds decisions the record never stated, and the record holds reasons and limits the code never showed. Each holds what the other lacks.

Decisions that never arrived

The second failure is the one the guard does not reach, and it needs a word on how OpenSpec keeps its record. A project has main specifications, the consolidated statement of what the system does. Each change gets a folder with a proposal, a design, a task list and delta specifications: the requirements the change adds, modifies or removes. When a change is complete it is archived. Its deltas are folded into the main specifications, and the folder, design and task list included, moves into an archive.⁵

The comparison drew up 71 decisions that the code makes and the main specifications do not state, and searched the 21 archived changes for each. One turned out to be stated in a main specification after all. Sixteen are decided in an archived design, task list or proposal: the weights that rank search results, default limits, a one-second pause before reloading, timeouts. Thirty-two are touched there without being decided. Twenty-two appear nowhere. The sixteen were chosen deliberately and reasoned well. They exist, but only inside the change that introduced them, in documents the archive step leaves behind. The external contract (every operation name, argument and response field a client depends on) is not named in the main specifications at all.

This is structural, not a lapse. A design document is where a change works out its decisions, and archiving keeps it as history. The trouble is that the history is the only place the decision lives. Three patterns sit behind the six places where the record contradicts the code or itself.

The first is change-local reasoning. An early change added a component that watches the folder for edits and triggers a reload. A later change introduced a rule that hidden directories are skipped, and argued it thoroughly for the component that reads the files. It never mentions the watcher, which still watches every directory, so activity in a hidden version-control folder triggers reloads. Each change reasoned well about itself. Nothing in the process asked which earlier mechanisms a new rule affected.

The second is that designs are not read again once archived. One design states that the specification requires an absent description to be distinguishable from an empty one. No version of the specification ever required that for descriptions, only for tags. The design invented the requirement, a code comment copied it, and the data type could not implement it: this is the comment the reverse test had flagged as a likely defect. Another design gives a reason for the order in which a link target is decoded and its trailing fragment cut off, and the reason is backwards. The order it defends is what breaks an encoded “#”, so a file whose name contains one cannot be linked at all. The main specification adopted the order. A wrong reason became the specification of record, because it sat in a document nobody read again, apart from the rule it justified.

The third is that tests became the specification for edge cases. The record says the starting point of a neighbourhood appears in it only if it is “genuinely reachable from itself”. Read literally, that holds in every neighbourhood that ignores the direction of links, since any link leads back. The implementing agent narrowed it sensibly to a document that links to itself, tests pinned the narrowing, and the specification never said so. A reader of the record cannot know the behaviour. A reader of the tests cannot know it was a decision.

Parnas and Clements stated the condition these patterns violate. No design decision counts as made until it is in the documents, and a change that invalidates a document requires that document, and every one after it, to be revised as if the change had been the original design.⁶ They asked for a record of what is decided, presented as if it had been decided rationally. OpenSpec’s archive keeps something else of value, the history of how it was decided. The gap is that the decisions stayed inside the history.

The proposal’s own pipeline has the same gap, drawn in plain sight. Findings flow back to authoring from two places, the conflict checker and operation. Nothing comes back from the coding agent or the tests. Whatever is decided while building has no way into the specification, and the conflict checker, however good its solver, can only compare what the rules say. A decision that never arrived is invisible to it.

The proposal said checking belongs at the point of change: that rule and its neighbours. The evidence shows what a neighbour is not. The watcher was not near the file reader in any document, and it was not part of the same change. It shared a notion with the new rule, which files count as part of the input, and that was enough to be affected. The condition can be stated without a mechanism: the effects of a change on existing decisions have to be searched for, not remembered. Implementation produces information that a specification written beforehand could not contain.⁷ This system shows where that information went: into code, tests and archived designs, almost never back into the specification of record.

The contradictions surfaced because the derived specification was a second reading, independent by construction: the agent that wrote it never saw the record. That is the argument the proposal made for keeping the test agent and the coding agent apart, seen from the side of the specification. Two independent readings can be compared, and a single reading cannot be checked against anything. The derived specification itself had one reader, and nobody has read it a second time.

Names before code

One gap belongs to the proposal alone, and it came out of the discussion that followed the findings, not out of the test. The proposal kept the test agent and the coding agent apart: each reads the specification, and neither sees the other’s output until both are done. But a test has to call something. Before the coding agent starts, the functions, types and modules it will create have no names, and the test agent cannot call what does not exist yet. Independent tests can only attach where an interface was named before either agent began. That makes the interface part of the specification, and the proposal never said so.

On the cash machine, a test agent can check that $80 is refused only if it knows how to ask for $80 and what a refusal looks like. Whoever fixes those two things fixes part of the contract. If nobody does, the coding agent invents them, the test agent has nothing to call, and the arrangement falls back to the single reading it was built to avoid.

What this does not show

The evidence is narrow. It comes from one small system. The derived specification had a single reader, and errors in it would go unnoticed. The test was not blind: the reading agent knew the format and was asked whether it could hold the system, not whether people writing ahead of the code would produce it. Some of what is said here about libraries rests on knowledge of how they behave, not on observing them.

Precision needs the same caution. The record’s main specifications hold 351 scenarios, roughly one concrete case each. The derived specification holds 256 scenarios and, with its Examples tables, about 750 concrete cases. Part of that difference is hindsight, since the derived version was written with the code open and the record before the code existed. What the comparison shows is narrower than one format being more precise than another: the discipline found the gaps where it was applied. Whether a business author, writing ahead of the code, would find the same ones is untested. So is the purpose the proposal gave the format, a description from which an agent derives tests that check something, because no one can read the volume of code agents produce. The test derived no tests. Each of the 34 open questions marks a case where a test agent would otherwise have had to invent the expected outcome, the oracle problem the proposal described, but that is a reading of the evidence, not a measurement.

I am working on a skill for the business side and on tooling for development, both built on Guarded Gherkin and on these findings. Neither has been tried on a real change yet, and both will have to pass the kind of test the proposal has just been through.

The two failures are not equally hard. A decision nobody made can be forced: write the Otherwise, and someone has to answer before a library does. A decision made in the wrong place cannot be forced from inside a rule. It was made, and often reasoned well, and it stayed where it was made. A format can make someone decide. It cannot make the decision arrive.

P.S.: Since writing this essay, I’ve been building tooling around an extended, yet still Guarded Gerkin based spec format. And I use the format itself to do so, which is the first proof of whether it has utility and can carry an application.

P.P.S: It’s public.

¹ See also “Provided, Otherwise: The Missing Guard in Gherkin”, which introduces the format, its two writing rules, and the pipeline of authoring, test and coding agents that this essay reads against the findings.

² PARNAS, David Lorge and CLEMENTS, Paul C., 1986. A rational design process: How and why to fake it. IEEE Transactions on Software Engineering. SE-12(2), pp. 251–257. DOI 10.1109/TSE.1986.6312940. Avoiding requirements decisions made accidentally while designing is among the reasons for a requirements document (p. 252); most requirements documents ignore undesired events and leave the decision about what to do to the programmer (p. 253).

³ NYGARD, Michael, 2011. Documenting architecture decisions. Cognitect blog. 15 November 2011. His records are scoped to architecturally significant decisions. The decisions lost here were mostly behavioural (defaults, names, edge cases), which fall outside that scope.

⁴ PARNAS and CLEMENTS, A rational design process, p. 256.

⁵ OpenSpec, Fission AI: github.com/Fission-AI/OpenSpec. The project’s README shows a change folder holding a proposal, specifications, a design and tasks, and archiving as moving the folder to openspec/changes/archive/ while the main specifications are updated.

⁶ PARNAS and CLEMENTS, A rational design process, pp. 254–256. A change that invalidates a design document requires it and all later documents to be revised as if the change had been the original design (pp. 254–255); every fact has one, and only one, place (p. 255); no design decision is considered made until it is incorporated into the documents (p. 256). The paper describes an ideal process that, by its own account, no project follows. What is borrowed here is the state of the record, not the order of work.

⁷ See also “The Spec Is Not the Method”, on why contact with implementation produces information a specification written in advance cannot hold, and what follows for spec-driven development.

Decided Elsewhere was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

An internal IT organisation receives its budget once a year, and with it an expectation that is rarely written down but always present: next year, more for the same money, or the same for less. The budget is a number. The demand placed on the organisation is not. The backlog grows faster than it is worked off, every request arrives marked as important, and the prioritisation meeting has become the place where disappointment is allocated rather than work. However much the organisation delivers, it is perceived as slow, because what it delivers is measured against what it has been asked for, and what it has been asked for has no upper bound.

This is the ordinary condition of a cost centre. Mary Poppendieck described it plainly: a cost centre is measured on its costs and little else, its budget rarely rises when times are good, and it is the first to be cut when they are not.¹ Inside that frame, the demand side looks like a nuisance to be managed. It is more than that. It is the reason the efficiency the budget holders expect cannot show up where they are looking for it.

Where the gains go

In 1865 William Stanley Jevons argued that it is “wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption.”² Cheaper use of coal widened the uses to which coal was put, and consumption rose. Transport economists later found the same pattern on roads: adding lanes to congested highways brings more traffic, roughly in proportion to the added capacity, and the new traffic is mostly created rather than diverted from elsewhere.³

The road case is the closer analogy, because of the currency in which the price is paid. A driver on a free road pays in time. Yoram Barzel showed that when a good carries no money price, waiting becomes its whole price, and demand responds to it exactly as it would to a price in money: fall, and more is demanded.⁴ A requester in internal IT is in the same position. Asking costs nothing in money; the only price is the wait. When IT becomes more efficient and delivers more, the wait shortens somewhat, requests that were not worth waiting for become worth making, and the capacity gained is taken up by demand that did not exist before. The wait need not return to where it was. What returns is the full backlog.

The consequence is easy to state and hard to see from above. An efficiency gain can be taken in one of two forms: as lower cost for the same output, or as more output for the same cost. With demand unconstrained, the organisation does not get to choose. The choice is made silently and always in favour of output. And because the backlog does not shrink, the added output is invisible too. Management sees neither the saving it expected nor the extra delivery it received.

The usual response is to defend the budget by arguing for the value of what IT delivers, in business cases, benefit estimates and value scores. That route does not hold, for reasons argued at length elsewhere: the worth of a specific piece of work is a counterfactual no instrument can read, so it cannot serve as the signal that justifies a cost or steers a portfolio.⁵ There is a different lever, and it sits on the other side of the ledger. Instead of justifying the cost, limit the demand. The claim is not that the absorbed demand is worth little. Nobody can know that. The claim is that without a limit the organisation has lost a decision it should own: whether a given efficiency gain is to be taken as cost or as output.⁶

Why nothing limits it

In a market, placing an order is not free. Whoever orders commits to pay on delivery, and that commitment limits demand. It also carries information: a buyer who pays reveals, at least, that the purchase was worth the price to them.

Internal IT is the special case. The requester does not pay, or pays in a way that never reaches them in a feedback loop they perceive. The budget is held elsewhere, the charge, if there is one, lands on a cost centre, and the person who asked for the change experiences none of it. Health economists have a name for the result. When insurance reduces the price of care at the point of service to zero, demand rises wherever it responds to price at all. Mark Pauly called this moral hazard and was careful to add that it has little to do with morals: it is rational behaviour, because each user bears only a sliver of the cost of their own use.⁷ The same holds for the business colleague who files one more request. Nothing about the request is illegitimate. It is simply free.

Pauly also reports an observation of James Buchanan’s about the British National Health Service that fits internal IT uncomfortably well: people demand care as though it were free, yet when they vote on the budget, they provide for less than they demand. An organisation does the same with its IT. The budget is set centrally, with cost in view. The demand is exercised locally, with cost out of view. Both decisions are reasonable where they are made, and they do not add up.

Donald Reinertsen put the requirement into a single principle for product development: “ensure decision makers feel both cost and benefit.”⁸ The internal requester is a decision maker who feels the benefit and not the cost. Demand then does two things. It grows without limit, and it stops carrying the requester’s own estimate of what a request is worth to them, since nothing forces that estimate to be made. Many requests may matter little to those who make them; nobody can tell which.

This is a claim about internal services, and only about them. It does not generalise to markets, where the promise to pay is itself the cost.

Three limiters that miss

Organisations do limit demand, whether they intend to or not. The three common ways each fall short, and the way each falls short points to what a working limiter would need.

The first is the queue. Waiting does limit demand, as Barzel’s analysis requires, but it does so by consuming what it rations. For the marginal person in a queue, the time spent waiting exhausts the entire worth of the good: in his phrase, “If there is a free lunch, it will come to have zero value.”⁹ The queue also selects by the wrong property. Who waits depends on how cheap waiting is for them, not on how much the thing waited for matters. And in IT it rewards a further behaviour: requesting early and speculatively, to hold a place in line for something that may be needed later.

The flow tradition’s answer is admission control. Poppendieck’s advice to firms facing more demand than they can serve is not to accept work faster than the bottleneck completes it, and then to grow capacity to meet the rest.¹⁰ WIP limits at the commitment point do the same inside the system. Both protect flow. Neither limits demand. They move the queue upstream of the point where work starts, and the requester’s price is still the wait. Her second step, growing capacity, is exactly what unconstrained internal demand absorbs. And a firm can turn customers away. An internal IT organisation generally cannot turn away its own business.

The second limiter is a budget or a price. Chargeback bills departments for what they use; showback shows them the cost without billing it. Reinertsen goes further and proposes internal markets to decentralise control, and prices that rise with congestion to push demand out of busy periods.⁸ On roads, where the traffic economists concluded that only congestion pricing is left as a remedy, this works because the driver pays.³ Inside a company it does not, because the money lands on a budget and the budget belongs to someone other than the person asking. A price paid by the cost centre changes the cost centre’s accounts, not the requester’s behaviour. The variant that reaches the requester directly is a quota: Kent Beck suggests giving customers a share of development capacity to use as they please.¹¹ A quota does make each requester ration. But sizing the shares means deciding in advance where capacity will pay off most, which is the same value knowledge that the budget route lacks.

The third limiter is the hurdle: the request form, the business case template, the approval step. Public economics calls these ordeals, deliberately imposed costs that are pure deadweight, accepted because they sort applicants.¹² They filter. But they burn the time they cost, and they sort well only under conditions that, as the next sections show, internal IT tends to violate.

Each of the three either fails to reach the requester or destroys what it charges. A working limiter would need to do neither.

A cost that produces

There is a cost that reaches the requester personally and does not destroy what it charges: the requester’s own active participation in the work. Providing the information the work depends on, clarifying what is meant, taking part in refinement, reviewing early versions and saying what is wrong with them. Time spent this way limits demand, because it is time the requester must find. And it improves the result, because it is spent on the result.

Barzel draws the relevant distinction. A money price is a transfer: what the buyer pays, the producer receives. Time spent in a queue is captured by nobody.⁹ Participation adds a third case. Set side by side, the three mechanisms differ in what happens to the price once it is paid. An ordeal is negative-sum: the time is burned. A price is zero-sum: the money moves from one budget to another. Participation is positive-sum: the price is paid in a currency that raises the worth of what is bought. The comparison has a limited scope and should be read that way. It compares what each mechanism costs the organisation, not how accurately each one separates important requests from unimportant ones. Filtering is a different question, and it is the one on which participation struggles.

Why the time is productive in IT specifically has to do with what IT works on. In product development, the process a product supports usually lies outside the organisation that builds it. In enterprise IT, the work object is a business process running through systems the same organisation owns, and the process belongs to the business.¹³ The two sides then hold different halves of what a change needs. The business knows how it wants to work. IT knows which systems the process touches, how the data flows between them, and which governance and compliance obligations apply, much of which the business never sees. Elinor Ostrom, one of those who developed the concept of coproduction for public services, named the condition under which contributions from two parties produce more than either alone: the inputs must complement each other rather than substitute for one another, so that “each has something the other needs.”¹⁴ In enterprise IT that condition is met by construction. Collaboration is not a courtesy extended to the business. The work cannot be specified without it.

This answers the objection that arrives first: that the business experts are too expensive to spend their time with IT. Their time is a real cost, though a cost to the organisation, not to them. The honest comparison is not with an afternoon saved. It is with building without their knowledge, and with what follows from that. John Seddon calls demand caused by a failure to do something, or to do it right, failure demand, and argues that the greatest lever on a service system is to change the characteristics of its demand.¹⁵ Work built on a guess about intent comes back as rework and follow-up requests. Participation reduces that share. So it limits demand in a second way, not by deterring requests but by removing the ones the organisation creates for itself.

None of this makes coproduction a discovery. Ostrom and her colleagues developed the concept in the late 1970s. The Agile Manifesto’s fourth principle holds that business people and developers must work together daily.¹⁶ Beck lists real customer involvement as a practice, with the stated aim of cutting waste by bringing those who have the needs together with those who can meet them.¹¹ What these accounts share is that they treat participation as a benefit, something a customer might even pay for. What is proposed here is narrower: using the cost of participation as the limit on demand, so that the mechanism which constrains how much is asked for is the same one that improves what is built.

Where it breaks

A mechanism proposed as the answer deserves the same scrutiny as the ones it replaces, and this one has a structural weakness. It works through two effects, and they pull against each other.

The limiting effect needs the time to feel costly to the requester. The contributing effect needs the time to be given willingly and competently. A requester who resents the hours participates grudgingly, and grudging participation contributes little: the review is skimmed, the question is answered by whatever is quickest. A requester who enjoys working with IT, or has slack, contributes well and feels no limit. The mechanism works only in the band where the time is costly enough to make people choose and meaningful enough that they do not disengage.

The sorting also runs the wrong way. Albert Nichols and Richard Zeckhauser argued that ordeals sort well when their cost falls inversely with the benefit, so that those who need something most find the hurdle cheapest.¹² A time requirement in IT does the opposite. It is most expensive for the busiest people, and the busiest are often the domain experts with the most consequential requests. Left to itself, a participation requirement deters first the requesters whose participation would help most. And where IT could in fact do the work alone, where in Ostrom’s terms the inputs substitute for one another, participation adds nothing and becomes an ordeal again.¹⁴

Then there are the two ways the cost escapes. The first is delegation. The requester sends someone junior, who has the time but not the knowledge. The limit disappears, because the requester is no longer paying, and the contribution disappears, because the person paying cannot supply it. The second is displacement, and in IT it is the default. The work of clarifying, specifying and deciding moves to a role on the IT side: the product owner, the business analyst, the requirements engineer. In IT that role often slides towards proxy for the business colleagues, and at its extreme towards order taker. Beck is blunt about proxies: working without a customer, or with a stand-in for one, produces waste: features that go unused, and tests that miss what acceptance really requires.¹¹ Displacement preserves the requester’s zero cost by design. It also meets a second obstacle. The role that absorbs the work would need to shape the business process to do it well, and business colleagues typically reject IT influence on how they work. That is Ostrom’s second condition failing: coproduction requires that both parties have real options, and here one of them does not.¹⁴

Last, incentives. Where requesters are rewarded for their “real” work, and their bonus depends on it, every hour spent with IT is an hour taken from what they are measured on. Participation under those terms will be grudging or delegated, whatever the policy says.

The failure-demand effect survives all of this in part, since fewer self-inflicted requests are fewer requests regardless of how willingly anyone participated. But it does not resolve the tension. It only means the mechanism is not all-or-nothing.

Who can install it

Every failure mode in the previous section has the same shape. The mechanism binds the requesters, and IT cannot bind the business. It cannot require business colleagues to participate, it cannot stop them from delegating, it cannot give its own roles influence over business processes, and it has no say over how business colleagues are rewarded. Whatever form the limit takes, it has to be put in place by someone with authority over both sides.

That is the lowest position in the hierarchy where business and IT share a superior. In a divisional organisation with its own IT, it may be the head of the division. In a company with a shared IT function, it is the chief operating officer or the chief executive. The position that can install a limit on demand is, in the typical case, the one furthest from the work.

What that position has to do is specific, and the form matters. Ostrom’s fieldwork includes cases where coproduction withered under top-down command: central authorities took over schools that villages had regarded as their own, ran them by decree, and village contributions dwindled.¹⁴ A decree that the business shall participate would repeat that failure. The top position’s job is to make the requirement binding, so that participation is a condition for work to start, not a favour IT can only ask for; to give both sides real options, including IT’s standing to shape the processes it builds; and to remove the incentives that punish participation. How participation happens is best left to the people doing it.

The same office holds the expectation of yearly efficiency gains, the authority to limit demand, and the incentives that decide whether participation is real. That is the case to take to it. Without a limit on demand, an efficiency gain in IT can only ever appear as more output, never as lower cost, and no amount of value justification will change the arithmetic. With a limit, the organisation can decide which of the two it wants. The limit that serves this purpose best is not a price and not a hurdle. It is the requirement that those who ask for the work take part in it.

¹ Mary Poppendieck, “The Cost Center Trap”, Lean Essays, 5 November 2017, https://www.leanessays.com/2017/11/the-cost-center-trap.html. Her remedy, steering IT by business outcomes, is a form of value steering; see note 5.

² William Stanley Jevons, The Coal Question, 1st ed. (London and Cambridge: Macmillan, 1865), ch. VI, “Of the Economy of Fuel”, p. 103.

³ Gilles Duranton and Matthew A. Turner, “The Fundamental Law of Road Congestion: Evidence from US Cities”, American Economic Review 101(6) (2011), 2616–2652. The authors conclude that neither more roads nor more public transit relieves congestion, leaving congestion pricing as the main candidate remedy (p. 2646).

⁴ Yoram Barzel, “A Theory of Rationing by Waiting”, Journal of Law and Economics 17(1) (1974), 73–95, at p. 75.

⁵ See also “Steering by Value: The Signal That Isn’t There” for why the worth of a bet cannot serve as a control signal.

⁶ See also “Steering by Value: The Only Decision You Control” on the commitment as the one decision fully in anyone’s hands, and why it has to be an owned judgement

⁷ Mark V. Pauly, “The Economics of Moral Hazard: Comment”, American Economic Review 58(3), Part 1 (1968), 531–537, at pp. 532, 534–535. The observation attributed to Buchanan is reported in Pauly’s note 1, p. 533, citing James M. Buchanan, The Inconsistencies of the National Health Service (London: Institute of Economic Affairs, 1964).

⁸ Donald G. Reinertsen, The Principles of Product Development Flow (Redondo Beach: Celeritas, 2009): E14, the First Market Principle (p. 42); F4, the Principle of Congestion Pricing (p. 176); D20, the Second Market Principle (p. 262).

⁹ Barzel, “A Theory of Rationing by Waiting”, pp. 74, 80, 83 (note 16), 87–88.

¹⁰ Mary Poppendieck, “When Demand Exceeds Capacity”, Lean Essays, 11 June 2022, https://www.leanessays.com/2022/06/when-demand-exceeds-capacity.html

¹¹ Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd ed. (Boston: Addison-Wesley, 2004), ch. 9, “Real Customer Involvement”.

¹² Albert L. Nichols and Richard J. Zeckhauser, “Targeting Transfers through Restrictions on Recipients”, American Economic Review 72(2) (1982), 372–377, at pp. 376–377.

¹³ See also “The Estate Is Not a Tree”, section “Why this lands on IT”, on why the business process runs inside the enterprise IT estate, not beyond it.

¹⁴ Elinor Ostrom, “Crossing the Great Divide: Coproduction, Synergy, and Development”, World Development 24(6) (1996), 1073–1087, at pp. 1073, 1079–1082; the Nigerian cases at pp. 1076–1078.

¹⁵ John Seddon, Freedom from Command and Control: Rethinking Management for Lean Service (New York: Productivity Press, 2005), pp. 37–38.

¹⁶ “Principles behind the Agile Manifesto”, 2001, https://agilemanifesto.org/principles

Limited Budget, Unlimited Demand was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

That sentence is worth stopping on, because it makes a claim that the field it belongs to had already written down the negation of, fourteen years earlier, in the paper that gave the field its name.

The predicate that needs an object

Friction is a well-defined thing to remove. A build takes forty minutes; it could take four. An environment takes two days to provision; it could take twenty minutes. A review sits for a week; it could sit for an afternoon. Each of these is a cost imposed on the person doing the work, each is measurable, and each can be driven toward zero. The programme has a floor and the floor is reachable.

What sits outside that programme is not a further quantity of friction. It is a property of the work rather than of the conditions around it: whether the thing being built is worth building, and whether the person building it can regard the contribution as their own.

The reason friction removal cannot reach that property is not empirical. It follows from what the words have to mean. “Well-built” is not a self-contained predicate. It means well-built for something, and the something is supplied from outside the craft. A team can hold a standard of construction against itself for a considerable time without external validation arriving, and that is what carries good engineering through a fallow quarter. But the standard is instrumental. Remove the object for long enough and the predicate loses its subject matter, and the questioning that follows does not need to arrive from outside; it arrives on its own, because the grounds for holding the judgement have run out.

I came at this from an observation I cannot treat as evidence. Leading a team some years ago, I watched the same people, with the same skills and the same tooling, move between a period in which the work was something to be proud of and a period in which it was not, and the only variable I could see moving was what the work was. I record that as the question rather than the finding. My own conduct changed across that boundary and I am the person least placed to see it; project transitions carry phase effects that travel with them; and the novelty of a fresh problem predicts the same energy under any account of challenge and skill, with no reference to whether the output mattered. The argument above does not rest on any of that. It rests on what “good” has to mean in engineering.

The dimension that was there at the start

Developer experience received its first formal definition in 2012, from Fabian Fagerholm and Jürgen Münch.² They built it on the trilogy of mind: cognition, how developers think about their working environment; affect, how they feel about it; and conation, which they defined as the factors affecting how developers see the value of their contribution — the alignment of their own goals with the project’s, and their commitment to it.

The same paper, surveying what was known about individual performance, cites Frederick Herzberg. It states the distinction plainly: motivator factors relate to the work itself and can increase performance, while hygiene factors are unrelated to the work itself and produce dissatisfaction when they are missing.³

Herzberg’s two-factor theory has taken serious methodological criticism and this essay does not depend on it being correct. What matters is the sequence. The founding definition of developer experience contained a dimension about the worth of one’s own contribution, and it contained, in the surrounding survey, the distinction between conditions and the work itself. Both were written down at the beginning. The claim that delight is what remains after friction is removed is not a proposition the field failed to consider. It is a proposition the field had already recorded the opposite of.

The 2022 empirical study by Michaela Greiler, Margaret-Anne Storey and Abi Noda retains the conative dimension, though its framework diagram renders it as “expectations” rather than conation.⁴ The interviews behind that paper are full of the variable. Participants describe providing value to the business as among the most important things about their work; one describes an unglamorous bug fix as rewarding because it unblocked the business. The worst experience reported is being near the end of something and having the direction change completely, with one participant estimating that roughly thirty per cent of their output was immediately replaced. Recognition appears twice, once as a factor and once as a barrier: a developer whose test-suite work went unvalued reports feeling underappreciated and stopping any work beyond their job description. The paper’s own conclusion is that the barriers to improving developer experience are primarily organisational rather than technical.

Friction as the ontology

The compression arrives in 2023, in a practitioner article by Noda, Storey, Nicole Forsgren and Greiler.⁵ The definition survives intact: developer experience encompasses how developers feel about, think about, and value their work. The model does not. Three dimensions are distilled from the earlier twenty-five factors — feedback loops, cognitive load, and flow state — and the article states what they are for. Taken together, the three encapsulate the full range of friction types encountered by developers.

Friction becomes the ontology of the field in that sentence. Two of the definition’s three verbs have somewhere to live in the model. The third does not.

What the model then measured is a matter of record, because the same authors, joined by Kalliamvakou and Houck, took it into the field.⁶ That study grounds itself in work design theory, and the choice is worth pausing on. Work design theory is the tradition that has spent five decades establishing which properties of a job produce motivation, and its canonical motivational characteristics include task identity — completing a whole, identifiable piece of work — and task significance, the degree to which the work affects other people.

What the study draws out of that tradition is that novel work and freedom from noise support focus, that easy-to-understand tasks and well-designed information flows contribute to outcomes, and that timely feedback supports personal performance. For the second of those it cites a meta-analysis of 259 studies and some 220,000 participants, and cites it for two characteristics: job complexity and information processing.

Those two are not drawn from a different part of that literature. They sit in the same list of motivational work characteristics as task identity and task significance. The meta-analysis reports that its own findings for job complexity and information processing rest on few studies and small samples and should be read with caution, and it names both among the characteristics that remain insufficiently investigated. It also reports, in what it describes as the first meta-analytic test of the model, that experienced meaningfulness is the psychological state through which motivational characteristics principally reach work outcomes, with strong support for that mediation in the cases of skill variety, task identity and task significance.

The two characteristics taken into the developer experience model are the two the source itself calls under-evidenced. The ones left behind are the ones carrying the mediation the source calls most important.

The instrument that resulted has fourteen items. Flow state asks whether the developer has significant time for deep work, how often they are interrupted by something unplanned, and whether their coding tasks are more engaging than boring. Feedback loops ask how long it takes to get a technical question answered and what percentage of code reviews complete within four business hours. Cognitive load asks about the ease of deploying changes, the ease of understanding the code, whether processes are easy to figure out, and whether the tools are intuitive.

Thirteen of those fourteen are readings on the conditions around the work. Take a team building something that matters and a team building something nobody will use, hold the tooling and the process constant, and every one of the thirteen comes back the same.

The outcome measures behave differently, and that produces the characteristic failure of the instrument. Whether a developer felt productive or creative, whether they are looking for jobs elsewhere, whether the organisation is meeting its goals: these move when work stops being worth doing. So the study can see that something has gone wrong, at the outcome end, and it has almost nothing on the input side that can account for it.

Almost nothing, because of the fourteenth item.

The one that crossed

Whether the coding tasks are more engaging than boring is not a measure of friction. It is a property of the work rather than of the conditions around it, and it sits inside the flow state construct as one of three.

The study’s own analysis puts it near the top. An importance-performance analysis identifies deep work and engaging work as the two items with the largest potential impact on developer outcomes, and names the same two again as giving outsized support to organisational outcomes including innovation, retention and profitability. Separately, developers who find their work engaging report feeling thirty per cent more productive than those who find it boring.

Then the authors write the recommendation that follows from it. Rethinking how tasks are distributed, they suggest, and asking whether particular teams are regularly given work they find boring, or divorced from the company’s mission and customers.

That sentence is the variable. It is in a practitioner-facing article by six of the field’s principal researchers, attached to one of the two most impactful items in their own model, published in the same year as the compression.

It appears in no framework built afterwards. Not in DX Core 4. Not among the sixteen drivers of the Developer Experience Index. Not in the speed, ease and quality of EngThrive. One item crossed from the theory into a fielded instrument, ranked at the top of the analysis, was glossed in prose as a question about mission and customers, and did not survive the next step.

Two further results from the same study are worth recording. The hypothesis that feedback loops improve outcomes was only partially supported: they influenced team outcomes and had no significant effect at the developer or organisation level. And meaning appears in the 2023 model only folded into flow state, as autonomy over work structure, clear goals, and stimulating and challenging tasks. That is the challenge–skill balance, which is a claim about the difficulty of the work. A task can be perfectly calibrated to a person’s skill and still be pointless.

What the instruments were built to hold

Three frameworks have since been built on that foundation, and each of them reaches for the variable and comes back holding something else.

The Developer Experience Index, DX’s commercial measure, is described by its authors as a formative measure of whether the right conditions exist for developers to deliver effectively.⁷ Its stated route to higher productivity is the removal of friction. Sixteen drivers — build and test, change confidence, clear direction, code maintainability, customer focus, decision-making, deep work, dev environment, documentation, ease of release, incident handling, incremental delivery, local iteration speed, planning process, production debugging, review turnaround — are combined into a single score, which the document describes as protecting the index from the volatility of individual metrics. Whatever any one driver contributes, it is averaged. And the composite is validated against outcomes led by efficiency and time loss, with the headline claim being that each one-point gain corresponds to thirteen minutes per week of developer time saved.

Customer focus is the driver that might reach the variable, and its item wording is not published. It is also, in most enterprise and commercial software development, a survey question about a relationship that runs through a service platform rather than through any contact with a person. Either way the point is the same: it is one of sixteen inputs to a number validated against minutes.

DX Core 4 names one of its four metrics “Impact” and operationalises it as the percentage of time spent on new capabilities rather than maintenance. That is an investment-allocation figure. Microsoft’s EngThrive, built independently, reaches the same place by a different route: its north star for ease is an innovation time ratio, dividing developer hours into innovation, running the business, and overhead. Both frameworks classify the work by accounting category. Neither asks whether the new capability was worth building. EngThrive’s north star for speed, idea-to-customer, is glossed as measuring how long it takes to turn intent into impact, where impact means elapsed time and the intent is not the developer’s.

There is now a census of this landscape. In 2026, André Meyer, Patrick Meyer, Gail Murphy and Thomas Fritz curated the metrics in circulation across the scientific literature and the published practice of more than fifty engineering organisations.⁸ The dataset holds a hundred and twenty-two metrics, organised across eight dimensions.

One of them reads on whether the work was worth doing. It is called Impact, and its definition covers tangible outcomes and value delivered rather than raw output, and making significant contributions to one’s business unit so that the work has tangible effect. It ranks forty-sixth of a hundred and twenty-two by how many sources reference it. One company. Three research papers.

Developer satisfaction ranks first, cited by twenty-seven organisations and seventeen research sources. Adoption rate, the uptake by developers of the internal tooling they have been given, is cited by nineteen organisations. Daily, weekly and monthly active users for AI tools, a metric with a single research source behind it, is cited by seventeen.

The dataset records what organisations publish, not everything they do, and the claim should be scoped to that. What the field publishes and cites is a landscape in which the tooling’s uptake is measured nineteen times more often than the worth of the work it is used for.

The finding that never crosses

The obvious reading of that gap is that the field has not noticed. It has noticed repeatedly, and this is the part that makes the pattern worth describing rather than complaining about.

DORA’s 2024 report, working through a counterintuitive result about AI adoption, states in passing that the meaningfulness of development work derives from the impact of the solution created rather than from the writing of the code.⁹ The same report finds that organisations prioritising the end user produce higher-quality products with developers who are more productive, more satisfied and less likely to burn out, and that organisations can succeed without high delivery velocity and stability provided they are user-focused.

DORA’s 2025 report goes further and instruments the variable directly.¹⁰ Among the constructs it studies are authentic pride, using an established psychological measure; meaning of work; and psychological ownership, defined as the feeling that something is yours even when it does not belong to you. Pride rose with AI adoption, and the report’s own account of the mechanism runs through contribution rather than craft: more time on work perceived as valuable, and higher pride as a result. Meaning of work showed no movement at all. Psychological ownership was studied against one question — whether writing code with AI assistance makes the code feel less like yours — and found no association.

In 2026, Rudrajit Choudhuri, Eirini Kalliamvakou, Brian Houck and Thomas Zimmermann mapped developers’ daily work across four dimensions, two of which are value and identity.¹¹ They report that the gap between how developers work and how they want to work has not closed as AI adoption has risen, and has if anything widened, which leads them to suggest that framing AI as a tool that reduces toil and frees time for meaningful work may be too simple. Their most pessimistic projected future is a role in which humans approve machine-generated work at industrial scale, accountable for outcomes they do not fully understand and rewarded for the volume of approvals rather than the depth of the craft.

Five findings, across fourteen years, all pointing at the same variable. And the researchers are not a separate community from the framework builders. Storey appears on the 2022 study, on the 2023 compression, and as chief scientist at the vendor whose index the 2023 article’s lead author founded. Houck appears on EngThrive and on the 2026 identity study and has since joined that vendor. Forsgren, Greiler, Noda, Kalliamvakou and Zimmermann recur across the whole sequence.

The same people find it and then build instruments that cannot hold it.

Conditions, guardrails, environments

Where the variable does enter an instrument, it enters in a consistent grammatical position, and the position is the argument.

The DXI measures whether the right conditions exist. EngThrive’s dashboards deliberately exclude the individual level, on the stated grounds that the system measures the environment developers work in rather than the developers, and that managers are accountable for the environment they create. And where meaningfulness appears in EngThrive at all — it does appear, imported from Microsoft’s employee sentiment programme, which asks whether people feel empowered, energised, and that their work is meaningful — it sits inside the thriving guardrail, alongside a satisfaction score. The metric the organisation steers on within that guardrail is bad developer days, a composite of context switching, incident toil, build failures, insufficient focus time and compliance obligations. Fifty-two per cent of developer-days qualified.

A guardrail is a constraint. It is a thing not to be violated, and nobody optimises toward one. Conditions are provided to a population by a party that is not that population. An environment is something you find yourself in.

That grammar has a history. The research DORA’s four delivery metrics were drawn from was conducted in organisations where the team that wrote the software also owned the system that shipped it, and the deliberate separation of those two — a platform team operating the delivery machinery, delivery teams consuming it through a self-service interface — opened a gap between the unit being measured and the unit determining the measurement.¹² That separation is correct on every axis anyone measures, and it is not the subject of this essay. But it did two things and only one of them has been noticed. It broke the metrics’ legibility as statements about the team, and it converted a portion of what a team had authored into something a team was given.

The second of those is the half of the variable this essay began on. Whether a person can regard a contribution as their own turns on the decisions that determined how the thing came out, and a delivery system a team is handed contains none of theirs. Whoever built it may be proud of it, and that is a real achievement; the pride does not travel with the artefact to the people who receive it. The machinery itself was a chore for many teams and they were glad to be rid of it, so what went is not the machinery but the judgement inside it. And it goes unevenly, in the same way the legibility does: where the interface is thin and teams make real choices above it, most of that judgement stays with them, and where it is thick and gated, it does not.

DORA’s own recommendation, in the same 2024 report that names user-centricity as the strongest driver it found, is that internal developers should be treated as users, and internal platforms built as products delivering value to them. “User” is a role defined by not having made the thing. That is not a criticism of platform engineering, which is the right arrangement for most large organisations and produces better machinery than any team would build alone. It is an observation that the arrangement has a cost on an axis the instruments do not read, and that the construct which would read it — psychological ownership — exists in the field’s own toolkit and has been pointed at one question, about AI, and never at this one.

The list that includes the weather

EngThrive’s authors anticipate the obvious objection to all of this, and their answer is what makes the omission legible rather than inferred.

In a section on applying the framework beyond developer tools, they observe that a developer’s experience is shaped by factors that have nothing to do with software, and that many of those factors are outside an engineering leader’s power to change. They then reject that as a reason to leave anything out: measuring the impact of a factor is worthwhile even when the lever belongs to someone else, because a quantified effect gives leaders evidence to take to whoever can pull it.

Having stated that principle, they list what the framework has been applied to. Office buildings, where daylight and ventilation account for up to a ten per cent difference in engagement. Seattle weather, where snow days show up as an eighteen per cent drop in output. Vacation policy. Return-to-office mandates. The ratio of product managers to developers. Manager span of control. Organisational bureaucracy.

Whether the work was worth doing is not on the list.

The principle is theirs, the list is theirs, and the omission is visible against their own stated inclusiveness. No account of anyone’s motives is needed to describe it, and none would improve it. The framework was built to be a general-purpose language for evaluating anything that shapes the experience of engineering work, and it evaluates the ventilation.

What was never weighed

Set the whole sequence out and the shape is not one of decline. Nothing was lost. The dimension was named in 2012 and is still being measured in 2025; the finding was published in 2024 and republished in 2026; the constructs exist, validated, in the field’s flagship annual research. The variable has never gone missing.

What has never happened is that it entered an instrument as something to be improved rather than something not to be broken.

And that is why the thing reads as a discovery each time it is found. A measurement system defines what an organisation can be seen to be getting better at. Speed, ease and quality can be steered toward. Conditions can be provided, guardrails can be held, environments can be improved by whoever is accountable for them. Whether the work was worth doing sits at a different address, and the instruments that would have to carry it there are commissioned, built and read by people whose authority stops short of it.

So no organisation decides against it. There is no meeting at which the trade is made, no budget line where the two are compared, no dashboard on which one goes down as the other goes up. The choice is made on the axis that has numbers, by people acting reasonably on the best instrument available to them, and the other axis is not weighed and found wanting. It is not weighed.

¹ Brian Houck, Tim Bozarth, David Liu and Dean Carignan, “EngThrive: Make It Fast and Easy to Do Great Work,” 2026 (arXiv 2605.04259; also ACM Queue). The sentence closes the paper’s discussion of why thriving is framed through a friction composite rather than through delight.

² Fabian Fagerholm and Jürgen Münch, “Developer Experience: Concept and Definition,” Proceedings of the International Conference on Software and System Process (ICSSP 2012), 73–77. The conative dimension is set out in section III and in the paper’s conceptual framework diagram.

³ Frederick Herzberg, Work and the Nature of Man (1966), cited by Fagerholm and Münch in their survey of factors influencing individual performance. The two-factor theory has been criticised extensively on methodological grounds, principally that its asymmetry is an artefact of the critical incident technique and of self-serving attribution; see Robert House and Lawrence Wigdor, Personnel Psychology 20(4), 1967, and Nathan King, Psychological Bulletin 74(1), 1970. The argument here does not require the theory to hold.

⁴ Michaela Greiler, Margaret-Anne Storey and Abi Noda, “An Actionable Framework for Understanding and Improving Developer Experience,” IEEE Transactions on Software Engineering, 2022. Twenty-one semi-structured interviews.

⁵ Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, “DevEx: What Actually Drives Productivity,” ACM Queue 21(2), 2023.

⁶ Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck and Margaret-Anne Storey, “DevEx in Action: A study of its tangible impacts,” ACM Queue, November–December 2023; also Communications of the ACM 67(6), 42–51, 2024. The survey instrument is reproduced in the article’s Table 1. The study is cross-sectional, with 219 completed responses from 2,213 invitations, among developers at customers of one of the authors’ companies — limitations the authors state. Its work-design grounding is drawn principally from Sharon Parker, Toby Wall and John Cordery (2001) and from the meta-analysis of Stephen Humphrey, Jennifer Nahrgang and Frederick Morgeson (2007).

⁷ Abi Noda and Laura Tacho, “The one number you need to increase ROI per engineer,” DX. The sixteen drivers are listed in the document’s overall model diagram; its prose refers to fourteen dimensions.

⁸ André N. Meyer, Patrick Meyer, Gail C. Murphy and Thomas Fritz, “Too Many DevEx Metrics, Too Little Guidance,” ACM Queue, 2026. The dataset is open and the counts above are taken from it rather than from the article’s summary of it.

⁹ 2024 Accelerate State of DevOps Report, DORA. The report’s own reading of the AI results, which it calls the vacuum hypothesis, differs from the use made of them elsewhere; the observation cited here is from its discussion of what respondents judge to be valuable work.

¹⁰ State of AI-assisted Software Development, DORA, 2025. Authentic pride is measured using the instrument of Tracy, Cheng, Robins and Trzesniewski (2009).

¹¹ Rudrajit Choudhuri, Eirini Kalliamvakou, Brian Houck and Thomas Zimmermann, “The AI-Native Developer,” ACM Queue 24(2), 2026. Surveys of 1,300-plus developers and interviews with 22 AI-fluent practitioners. The characterisations above follow Houck’s own summary of the study rather than the article text.

¹² An earlier essay works through what that separation does to the four delivery metrics, and why the degradation is invisible from the metrics themselves: The Seam DORA Can’t See.

What DevEx Keeps Finding and Never Carries was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

For decades, code was where ambiguity surfaced. A developer reading a vague requirement had to decide what it meant, and the decision showed up in a pull request, a question in a stand-up, a bug report. When an agent writes the code, that friction disappears. The agent decides silently, and its decision looks exactly like the intended one.

So the specification has to carry more than it used to. It has to be precise enough that an agent cannot misread it, and structured enough that a second agent can derive tests from it that check something. The most common format for business-readable acceptance criteria, Gherkin, has a structural gap that matters precisely here. This essay describes that gap, proposes a small extension that closes most of it, and shows how agents can help on both sides: writing the specification and using it.

One word in a familiar scenario

The cash machine is the textbook example of behaviour-driven development. It goes back to Dan North’s Introducing BDD,² and versions of it appear in countless tutorials. A typical one reads:

Scenario: Account has sufficient funds
  Given the account balance is $100
    And the card is valid
    And the machine contains enough money
   When the Account Holder requests $20
   Then the ATM should dispense $20
    And the account balance should be $80
    And the card should be returned

It reads well. Most reviewers would accept it. But one line is not like the others. “The account balance is $100” describes the world before anything happens. “The machine contains enough money” does not. Enough for what? For the $20 that only appears in the When. The Given cannot be understood, let alone checked, without first reading the event it is supposed to precede.

This is not a timing paradox. The cash in the machine is ordinary prior state; it exists whether or not anyone walks up. What cannot exist before the When is the comparison between that state and the requested amount. The author has performed that comparison in their head and written down only the result.

That comparison has a name in other disciplines: it is a guard. A precondition is a fact about the state of the world. A guard is a relation between that state and the parameters of the event that arrives. In a statechart, it is written request(amount) [cash ≥ amount] / dispense. The condition sits on the transition, because that is where it belongs.

Gherkin has three places to put things: state, event, outcome. A guard is none of them. So authors push it into the Given, where it becomes an adjective that hides the very rule the scenario was meant to illustrate: enough, sufficient, valid, appropriate.

Why more examples don’t fix it

Gherkin’s defenders have a good answer, and it deserves to be stated fairly. Gherkin is an example language on purpose. A scenario is one instance, not a rule. With concrete values everywhere, the guard’s outcome is already determined by the data. The rule itself is meant to emerge across several instances, and Gherkin 6 even added a Rule keyword to name it:³

Rule: The ATM dispenses only if it holds at least the requested amount

  Scenario Outline: Cash availability
    Given the ATM contains <cash> in cash
     When the Account Holder requests <amount>
     Then the ATM should <outcome>

    Examples:
      | cash | amount | outcome            |
      | $500 | $20    | dispense $20       |
      | $20  | $20    | dispense $20       |
      | $10  | $20    | refuse the request |

For a threshold rule, this works. There is one boundary, the examples probe it, and a reader can infer the rule. The Rule line is prose, not executable, but the examples carry it.

Now consider what a cash machine does. It does not hold “money”; it holds notes. A machine with three $10 notes can pay out $10, $20 or $30, but not $25. A machine holding one $50 and three $20 notes can pay out $90, but not $80. The guard is no longer cash ≥ amount. It is “the amount can be composed from the available notes”, and that condition is non-monotone: there is no single boundary to probe. No small set of examples lets a reader reliably infer it. The examples remain correct; they simply stop explaining anything.

The same detail breaks the Then. With two $20 notes and four $10 notes, a request for $40 can be paid three different ways. “Then the ATM should contain…” is either nondeterministic, or it can only be pinned down by fixing the note-selection algorithm in the scenario. That is implementation detail leaking into a business specification. Gherkin has no way to say any valid combination.

So the gap is not that Gherkin cannot evaluate a guard. Every concrete instance is fully determined. The gap is that Gherkin cannot state a guard, and its fallback strategy, demonstrating the rule through examples, fails exactly for the rules that are hardest to get right.

What spec-driven tools do today

The newer spec-driven tools have quietly sidestepped the problem instead of solving it. OpenSpec,⁴ one of them, writes requirements as SHALL statements with scenarios underneath. Its scenarios use only WHEN and THEN:

### Requirement: Theme selection
The app SHALL let users switch between light and dark themes,
defaulting to the system preference.

#### Scenario: User toggles dark mode
- **WHEN** the user clicks the theme toggle
- **THEN** the app switches to dark mode and persists the choice

The Given is gone. The preconditions have not disappeared, though. They go to one of three places: into the When (“WHEN a user with insufficient funds requests a withdrawal”), into the SHALL sentence of the requirement above the scenario, or nowhere, with the state simply assumed.

The first option is closer to the truth than Gherkin. “WHEN the requested amount cannot be composed from the available notes THEN the ATM SHALL refuse” puts the guard on the event, where it belongs. But it pays a price: concrete data drops out. The format has moved from specification by example to specification by rule, close to the EARS requirement templates.⁵ Rules are naturally written in relative terms. The “enough” problem is no longer an occasional slip; it is how the format works.

For a coding agent that is convenient, because an agent generating code needs rules rather than examples. But it means that the boundary values, the cases where the guard flips, are left almost entirely to the agent’s judgement. And the third option, the unstated state, is the most dangerous of all. It is exactly what a model fills in from its training data.

The proposal: Provided and Otherwise

The fix needs two words that business people already read every day in contracts and insurance terms: provided and otherwise.

Given     the ATM holds one $50 note and three $20 notes
When      the customer asks for <amount>
Provided  the ATM can make up <amount> from its notes
Then      it pays out notes that sum to exactly <amount>
  And     its stock of notes is reduced by exactly those notes
Otherwise it refuses the request
  And     nothing else changes
  
  | amount | result  | why                       |
  | $90    | pays    | $50 + 2 × $20             |
  | $80    | refuses | no combination makes $80  |
  | $110   | pays    | every note in the machine |
  | $120   | refuses | exceeds the notes held    |

Read aloud, it is one sentence: given the ATM holds these notes, when the customer asks for $80, provided the ATM can make up $80 from its notes, it pays it out; otherwise it refuses and nothing else changes. Clunky on paper, perhaps. But anyone who has read a contract clause can follow it.

The extension comes with two writing rules. Both can be checked mechanically.

1. Given must not refer to the event. No enough, no sufficient, nothing that needs the When to be understood. A Given describes the world as it is.
2. Provided must refer to the event. A Provided line that mentions nothing from the When is really a precondition, and belongs in the Given.

Together they give the guard a precise definition: a condition that only makes sense once the event is known. That is the line the original scenario crossed.

Three smaller conventions complete the format. Otherwise is mandatory: every guard forces a statement about what happens when it does not hold, including the frame condition nothing else changes, and negative cases and frame conditions are among the things specifications most often forget. Outcomes may be relations: “pays out notes that sum to exactly the amount” admits every valid combination, which resolves the nondeterministic Then without dictating an algorithm. And named conditions must be defined: can make up the amount from its notes is a term, composable for short, and it belongs in a glossary with a definition and an owner. An undefined term in a Provided line is a visible hole, not a silent assumption.

Several guards with different consequences (“otherwise, if the balance is too low…, otherwise, if the notes don’t fit…”) become unreadable quickly. That is best treated as a signal to split the rule: one Provided, one Otherwise per rule.

None of this is new in principle. Event-B writes an event as ANY amount WHERE guard THEN action, with parameters, guard and effect as separate parts. Statecharts write event [guard] / action. Design by Contract lets preconditions refer to parameters. The separation of state, event, guard and effect is standard in formal methods, and formal notation never reached acceptance criteria because it is unreadable to the people who own the rules. Structured natural language has come part of the way. EARS, developed at Rolls-Royce for aero-engine requirements, makes the author separate the preconditions under which a requirement can be invoked from the trigger that initiates it, in plain words, not notation. Its ordering rule is telling: the preconditions must already hold when the trigger arrives. A condition that relates the trigger to the state has no slot of its own and ends up inside the trigger or in an IF clause, and nothing requires the alternative to be stated.

The closest relative is older, and was written for business readers from the start. The fully dressed use case, in Alistair Cockburn’s version, states its precondition as an assertion about the world at the moment the use case opens, attaches each extension condition to the step at which the system detects it, requires every condition to be handled, and lists minimal guarantees that hold however the use case ends.⁶ Precondition, guard, Otherwise and frame condition were all there, along with something close to the first writing rule. What the template does not have is the second. Its own example of an extension condition is insufficient funds: the condition sits on the right step, and the relation it stands for is left unstated. Nor does it carry examples to derive tests from. Gherkin, the format agile teams more often reach for today, kept the examples and has no slot for the guard, the alternative or the frame condition. Provided and otherwise put the slots back into the example format, in words the owners of the rules already use, with a rule that makes the guard state its relation to the event. That is all the extension (call it Guarded Gherkin) adds.

Upstream: an agent that asks instead of answers

The obvious objection to any richer format is that business people will not write it. In practice the objection understates the problem. Getting acceptance criteria written at all is hard; getting them in Gherkin is harder; getting examples is rarer still. Gherkin’s defence assumes examples that, in many organisations, nobody writes. That is a practitioner’s observation, not a measured result, but it changes what a format can ask for. They do not have to write it alone. An authoring agent, packaged as a skill that encodes the format and its rules, can sit beside them and take the writing off their hands, though not the answering. The crucial design decision is what that agent is allowed to do.

It should interrogate, not formulate. It flags relative terms in a Given and asks what they are relative to. It insists on an Otherwise for every Provided. It asks for examples on both sides of every guard, and checks that each condition in a Provided is varied by at least one example. It notices outcomes that would only hold under one particular implementation, and asks whether any valid outcome is acceptable. And it refuses to define a named condition itself, asking the owner of the rule to define it instead.

That last refusal matters most. An agent that helpfully writes “composable means…” has quietly taken over a domain decision that belongs to the business. In a familiar domain it will probably guess right, which makes the habit more dangerous, not less.

In an unfamiliar domain it has nothing to guess from. Acceptance criteria are written before any code, data or usage exists. For a new product, nobody has a reference: not the business, and not a model trained on yesterday’s software. This splits the holes in a specification into two kinds.

Structural holes follow from the form of the specification: relative terms, unvaried conditions, missing negative cases, ambiguous outcomes, contradictory rules. They can be detected in any domain, and an agent will find them more reliably than a tired reviewer.

Domain holes follow from what the specification is about. The note-denomination problem is one. Finding them requires knowledge of the domain. An agent can offer analogies (composability problems recur in quotas, capacity planning and licence pools), but analogies are prompts for a human, never answers. Nor does the authoring agent replace the person who knows the system. A domain hole is often found first by whoever will have to build around it, and the authoring session is a good place for that person to be.

The format helps with both. It makes structural holes checkable, and it turns domain holes into a list of undefined terms. That list is an honest statement of what is not yet known. It is exactly what an agent must not fill in on its own.

The result of authoring is therefore two artefacts, not one: the rules, and a glossary of conditions that the rules refer to. Rules point to terms, terms have definitions, definitions have owners. Most of the real domain knowledge lives in the glossary. It needs no special tooling: a plain list of terms, each with a definition and an owner, kept next to the rules, is enough.

Naming a condition is not yet naming the right one. A document tool that refuses to edit text while a comment thread is still open on it has a guard in the right place: provided the thread is open, refuse. Its instructions tell an agent to answer the comment, resolve the thread, then edit. An agent that follows them to the letter gets its edit through, and leaves its answer attached to deleted text in a closed thread, where the person who asked will not see it. The guard did what it said. What it said was a proxy. The condition that mattered was that the commenter had read the answer; “the thread is resolved” is a state the actor can set by itself.⁷ A Provided protects something only if it names the real condition, not one the actor can satisfy on its own. No format can check that. It is a question for the owner of the rule, and one more reason the authoring agent asks instead of answering.

Downstream: tests that check something

There are two ways an agent can derive tests from acceptance criteria, and they fail differently.

Literal translation turns each concrete scenario into an executable check. It is safe, and it is thin: three examples give three checks. For a non-monotone guard, that is almost no coverage.

Generalisation infers the rule and generates further cases. This runs into the oracle problem. Every added case needs an expected outcome, and the specification only supplies outcomes for the cases it states. So the agent invents the rule. Given “the machine contains enough money”, it will almost certainly invent cash ≥ amount. The generated tests will be green, consistent and wrong about denominations. Nobody notices, because they look exactly as intended.

The extended format changes this, because each part maps to a kind of test:

• Examples → example-based tests. They check the stated cases, including both sides of the guard.
• Provided plus a relational outcome → property-based tests. For every amount, money is paid out exactly when the amount can be composed, and the dispensed notes sum to the amount.
• Otherwise plus “nothing else changes” → frame tests. After a refusal, the balance and the note stock are unchanged.
• Glossary definitions → tests of the conditions themselves. composable behaves as its owner defined it.

The agent no longer has to invent the rule. It is stated in the Provided, and its terms are defined in the glossary. If a term is undefined, the agent stops and reports the gap instead of guessing.

One further rule matters as much as the format: tests and code must not come from the same context. An agent that derives both from the same reading of the specification will make the same mistakes in both, and the tests will confirm the code rather than check it. Validation only means something if the two interpretations are independent.

This is the arrangement proposed here: a test agent and a coding agent, each reading the specification on its own, neither seeing the other’s output before both are done. A failing test then becomes a signal rather than a verdict. One of the two misread the specification, and the specification decides which. Two independent readings can be compared; a single reading cannot be checked against anything.

A stricter variant, offered here as an outlook, not a recommendation, lets the coding agent see only the tests, never the specification. The tests become the full contract. Anything the test agent did not translate will not be built, so gaps show up as missing behaviour instead of silent interpretation. The variant carries three risks. The first is teaching to the test: an agent that sees only tests may special-case them (if amount == 80: refuse). Property-based tests derived from the Provided cannot be satisfied with a lookup table; example tests alone can. The second is lost vocabulary. Tests say what, not in which terms; a middle ground is to give the coding agent the glossary but not the rules, so that domain language arrives directly and behaviour only through tests. The third is a single point of failure. If the test agent misreads the specification, the code faithfully implements the misreading, so the test agent's output needs its own review against the specification.

Either arrangement gains from a device borrowed from machine learning, the hold-out set. Whatever tests the coding agent is eventually allowed to see, from the outset in the strict variant or as failures after the first round in the proposed one, a reserved set, ideally property-based, is used only for validation. Code that passes the visible tests and fails the hidden ones has overfitted.

The arrangement is not new either. Cleanroom Software Engineering, developed under Harlan Mills at IBM’s Federal Systems Division in the 1980s, handed testing to an independent certification team that built its tests from a specification of expected usage, with no knowledge of the design. Developers did not even execute their own code before it reached that team.⁸ Cleanroom stayed confined to organisations that could staff it with skilled and committed engineers.⁹ For agents, the separation itself costs almost nothing; what Cleanroom demanded of its engineers is another matter.

Across rules: conflicts become visible

A single rule can be reviewed by reading it. A system has hundreds of them, written by different people over years. Explicit guards make the whole set analysable in a way prose rules are not. Three kinds of conflict become detectable. Overlaps are two rules for the same event whose guards can both hold, with different outcomes: a contradiction. Gaps are combinations of conditions that no rule covers: undefined behaviour. And Otherwise clauses can collide, one rule saying “refuse, nothing else changes” while another says “log the failed attempt” for the same case.

Where the glossary defines conditions precisely enough, an agent can translate guards into logic and hand the overlap question to a constraint solver. The agent translates; the solver decides. The translation is still a reading of the glossary and needs review, but the verdict on whether two guards overlap no longer depends on anyone’s sense of the wording. In WHEN/THEN prose the same conflicts stay buried in the text.

The set of rules also needs maintenance. It should be a living specification of current behaviour, not an archive of every scenario ever written. Rules that no longer apply are removed; otherwise the set fills with stale and contradictory examples, and checking it gets more expensive the longer the system lives. Checking belongs at the point of change: when a rule is added or modified, check that rule and its neighbours, not the whole set, all the time.

Some holes will only ever be found in operation: an incident, a support ticket, a user doing something nobody anticipated. Those findings have to flow back into the rules and the glossary. Without that loop, “specify upfront, validate afterwards” is waterfall with a larger budget.

What this does not solve

It is tempting to read all of this as a path to provably correct software. It is not. A program can be proven correct only relative to a specification, and formal verification does exactly that. What cannot be proven is that the specification itself is right. Every check needs a checker, and that checker would need checking in turn. Verification ends somewhere; validation does not.

This is especially true at the start. Before anything exists, acceptance criteria are hypotheses about what will be useful. Treating them as settled facts, and freezing them into green tests, turns uncertainty into the appearance of certainty. The format cannot prevent that. It can only make the uncertainty visible: as undefined terms, as missing Otherwise clauses, as guards nobody has tested from both sides.

The realistic goal, then, is not correctness. It is making errors visible early and cheaply. Measured against that goal, Guarded Gherkin’s two keywords and two writing rules do more than their size suggests. The guard gets a home and stops hiding in the Given, the negative case becomes mandatory, and what nobody yet knows shows up as an undefined term, not as a guess that downstream agents quietly make on everyone’s behalf.

The extension also asks very little of the people who own the rules. It does not require them to think formally. It only requires them to say what happens when the condition does not hold. Most of them already do that in conversation. The use case once asked. Gherkin never has.

Follow-up: I tested this format against a running system: what it held, what it couldn’t, and where decisions went that never reached the specification. Decided Elsewhere

2ⁿᵈ follow-up: In the meantime, I’ve built spec-driven-development tooling to implement the idea; and it was built using the idea itself. It’s available on Github.

¹ See also “The Spec Is Not the Method”, on why the large-upfront form spec-driven development first took repeats a mechanism the field has already paid for. The argument here assumes the opposite kind of specification: one that stays open and is revised as findings come back.

² NORTH, Dan, 2006. Introducing BDD. Better Software. March 2006. Republished on the author’s site: dannorth.net/blog/introducing-bdd. North’s original scenario reads “the dispenser contains cash”, and its event, “the customer requests cash”, carries no amount; the insufficient-cash case appears only as a further scenario to consider. The “enough money” wording is the later tutorial form.

³ Cucumber, Gherkin Reference, section “Rule”: cucumber.io/docs/gherkin/reference. The keyword arrived with Gherkin 6 in 2018, to align the syntax with Example Mapping.

⁴ OpenSpec, Fission AI: github.com/Fission-AI/OpenSpec.

⁵ MAVIN, Alistair, WILKINSON, Philip, HARWOOD, Adrian and NOVAK, Mark, 2009. Easy Approach to Requirements Syntax (EARS). In: 2009 17th IEEE International Requirements Engineering Conference. Atlanta, Georgia, USA: IEEE. August 2009. pp. 317–322. DOI 10.1109/RE.2009.9. The paper builds on Event-Condition-Action rules, in which an event triggers the rule and a separate condition decides whether the action follows (p. 318); its own templates keep preconditions and trigger, with no separate condition (p. 319). Unwanted behaviour, which the authors found a major source of omissions, gets a syntax of its own (IF … THEN), not a counterpart required for every requirement. The motivation is the one shared here: formal and graphical notations create a language barrier between developers and stakeholders (p. 318).

⁶ COCKBURN, Alistair, [2001] 2011. Writing effective use cases. 23. print. Boston: Addison-Wesley. The Agile software development series. pp. 81–84, 100–103. ISBN 978–0–201–70225–5. Preconditions are enforced before the use case starts and not checked again during it (p. 81); minimal guarantees are the fewest promises the system makes when the goal cannot be delivered (p. 83). The extension “2a. Insufficient funds” appears on p. 103 and again on p. 108, where it is handled by asking the customer for a new amount.

⁷ Ibid., p. 102. His Guideline 11 asks that an extension condition say what the system detects, not what happened: not “customer forgets PIN” but a time-out. The proxy problem is the other side of the same discipline. A condition the system can detect is not thereby one the actor cannot set.

⁸ MILLS, Harlan D., DYER, Michael and LINGER, Richard C., 1987. Cleanroom software engineering. IEEE Software. 4(5), pp. 19–25. Full text. The three projects reported there reached system test without debugging (p. 19). The team structure is described in LINGER, Richard C., 1993. Cleanroom software engineering for zero-defect software. In: Proceedings of the 15th International Conference on Software Engineering. IEEE. pp. 2–13: software enters system testing “with no execution by the development team”, and the certification team has deep knowledge of expected usage but none of design internals. The functional specification is usually written by the development team, by a separate team only on large projects.

⁹ SOMMERVILLE, Ian, 2008. Cleanroom experience. Web companion to Software engineering, 9th edition. Sommerville notes that the method seems to work in the hands of skilled and committed engineers, and that reports of its use dried up after the late 1990s.

Provided, Otherwise: The Missing Guard in Gherkin was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

It does not matter which defect this is. If the specifics do not match your situation, the specifics were never the point; what matters is the shape. A piece of functionality that someone values is delivered by more than one team, and the thing that is wrong is not wrong in any one team’s work. It is wrong in the relationship between them. That shape appears wherever delivery crosses a boundary, whatever the boundary is made of. If your organisation ships anything that more than one team contributes to, you have it.

One thing is assumed throughout, and stated plainly so it is not smuggled: team-level quality discipline exists. Test-driven development, unit-level automation, the discipline that keeps a single team’s work honest, all taken as given. The defect above survived every bit of it. Both teams’ suites are green. Everything a competent team would reach for to catch this has already run and passed. The problem begins where team-level quality ends.

The defect with no home

Notice what cannot happen with the defect described above. It cannot be assigned. There is no team whose backlog it naturally belongs in, because no team produced it. It emerged from an interaction that no team owns, which means it has no native home in any team’s work system. Each team can look at it, verify that their own part is correct, and return it, truthfully, as not theirs.

This is the structural fact the rest of the essay rests on. The unit of value the stakeholder cares about does not coincide with the unit of ownership any team holds. The functionality spans a boundary that the ownership stops short of. The defect is real, it is reproducible, and it belongs to no one. This is not an organisational failure to assign it; it is that the thing it is wrong in is a thing no team was given to own.

What organisations build instead

The standard response to this is well established and nearly universal. Organisations create a function whose job is to see across the boundary: a dedicated quality-assurance group, a cross-system test team, an integration or end-to-end verification function. The names differ across organisations, but they pick out the same structural role: a position from which the constituent systems are simultaneously visible, staffed by people whose remit is the space between teams rather than the work inside any one of them.

This is the present-day default. It is what an organisation reaches for when it notices that no team owns the cross-boundary thing, and it is reached for so reliably that it has stopped looking like a choice. It is worth being clear that it is one.

What the default actually solves

The default does something real, and it is worth saying so plainly before saying what it does not do. It produces a real vantage point. Seeing a cross-boundary defect at all requires a position from which the interacting systems are visible at the same time, and no team has that position, because each team’s view stops at its own boundary. A dedicated function manufactures the missing vantage. That is a real solution to a real problem.

It is worth noticing, though, that the vantage is constructable in more than one way, and the dedicated function is only the most common construction, not the only one. The same cross-system visibility can be produced by the constituent teams’ own testers, working together across the boundary rather than each within their own team, provided the arrangement is set up so that the cross-boundary work has an explicitly agreed priority in each tester’s role, with all sides accepting that, when cross-boundary work and local work compete, the cross-boundary work almost always comes first. Stated that way the condition sounds modest. It is not, and the reason it is not is the subject of a later section. For now the point is narrower: there are at least two ways to construct the vantage, a dedicated one and a distributed one, and neither is privileged by the structure of the problem. The dedicated function is what organisations typically reach for, but typical is not necessary. What matters here is that both constructions solve the same thing, and solve it about equally well. That is the first sign that vantage was the part of the problem that could be solved by construction at all.

But getting the defect seen is not the same as getting it handled, and the gap between those two things is where the actual difficulty lives.

A cross-boundary defect, once seen, has to be resolved. Resolving it means work has to happen inside the constituent systems, the systems the verifying function does not control. And that work does not arrive into empty capacity. The teams that would have to do it have already committed their capacity to their own backlogs, under their own pressures, against their own definitions of what they are finishing. The defect that belongs to no one now has to displace work that belongs, very definitely, to someone, who did not produce a defect they can see and has no local reason to stop what they are doing.

So the vantage gets solved, by whichever construction, and the half that cannot be solved by construction is left untouched by either. The dedicated function sits outside the constituent teams’ delivery lines entirely; it has no standing over anyone’s committed work, and can see the defect with perfect clarity while having no native authority to cause anything to happen about it. The distributed construction is not obviously better off. A team’s own testers sit inside their own team’s line, but the cross-boundary defect needs pre-emption inside the other team’s committed work as much as their own, and over that they have no more standing than the dedicated function does. The two constructions differ in where they place the vantage; they do not differ on the thing the vantage cannot supply. The visible half of the problem gets solved in a way that leaves the invisible half exactly where it was, in nobody’s authority, and the visible solution is convincing enough that the invisible half stops being looked at. Something was built; it does what it was built to do; and what it does not do becomes harder to see precisely because something was built.

The coordination that nobody’s job produces

Step back from the verifier and look at what would actually have to be true for a cross-boundary defect to be handled without value delivery stalling behind it.

The constituent systems would have to be brought into a state where end-to-end verification can happen at all. That is not a state any team’s normal operation produces, because each team’s normal operation is oriented toward its own definition of done, not toward simultaneous readiness with teams whose cadence it does not share. Getting there requires sequencing and scheduling across teams so that the delay at the point where their work has to meet is minimised. That is coordination, and it is nobody’s job, because it is about the relationship between work systems rather than the work inside any one of them.

Then verification happens, and if it surfaces failure demand, defects produced by the interaction, the same coordination has to happen again, now on the way back: the failure demand has to re-enter the constituent systems, at high enough priority and fast enough, that it is resolved rather than queued behind whatever those teams had already committed to. And then verification has to happen again, because a fix to a cross-boundary defect is itself a cross-boundary change. The loop does not run once. It runs until there is no failure demand left, and each turn of it requires the same coordination that no team’s normal operation produces.

It is tempting to read this as a description of a process that should be designed and installed: a coordination role, a set of cross-team scheduling rituals, a defined return path for cross-boundary failure demand. That reading is the mistake. None of this needs to be designed if the system already has the property that produces it. A system whose participants are genuinely oriented toward finishing the thing of value converges on this coordination by itself, because the coordination is simply what finishing a cross-boundary thing consists of. The orientation that matters here is finishing the unit the stakeholder actually cares about, not starting work and not completing local slices. Reserving capacity against probable failure demand, sequencing toward the point where work has to meet, treating a cross-boundary defect as more urgent than local work: these are not interventions added to a finishing-oriented system. They are what a finishing-oriented system looks like when the thing being finished crosses a boundary.

“Stop starting, start finishing” is not advice this situation needs from outside. It is the principle the entire structure is an expression of. The dedicated verification function is what tends to get built instead. When the orientation that would have produced the coordination is absent, an organisation builds a structural prosthesis to stand where the missing disposition would have stood. A prosthesis that can see is still a prosthesis: it cannot make a finishing-oriented system out of one that is not, and it was never going to, because that was never a thing a function could be.

Why naming the principle is not nothing, and not enough

The argument so far could be read as fatalism: if the coordination only emerges from an orientation the organisation either has or does not have, and an orientation cannot be installed, then there is nothing to be done.

That is too quick. An orientation cannot be installed, but a principle can be named, explained, and stood behind. An organisation, or a part of one, that says this is how we operate, finishing the thing of value comes before starting or completing the parts of it, and here is why exerts real drag toward the orientation that produces the coordination. What this does is shape the conditions under which the stance is more likely to form rather than decree the stance itself: the difference between prescribing a destination and constraining the space, which earlier essays in this series have spent their length on and this one will take as established. The people who name the principle have to stand by it under pressure, including when standing by it is expensive, and that holding-under-pressure is its own subject that this essay will not reopen; it has been covered, and reopening it here is how an essay loses its shape.

So the principle can be named, and naming it does real work. The reason this is not enough is the subject of the next section, and it is the part of this problem that is genuinely under-described.

The expression that looks like its own betrayal

Here is what makes this difficulty resistant in a way that naming the principle does not resolve.

The concrete expressions of finishing-orientation, in a cross-boundary context, each look — locally, in the moment, to the person doing them — like the opposite of finishing.

Reserving capacity against failure demand that has not yet materialised, and might not, looks like idleness. A finishing-oriented team, told to hold capacity empty against a defect that does not exist yet, sees itself being asked not to work. Pre-empting work the team has already committed to, in order to absorb a cross-boundary defect that surfaced in something the team does not own, looks like not finishing what was committed, the precise thing a finishing orientation should forbid. Slowing one’s own implementation to collaborate closely with another team, rather than driving one’s own slice to completion as fast as possible, looks like the opposite of shipping.

In every case, the person being asked to do the correct thing holds the finishing orientation, and the correct thing presents itself to that person as a violation of the very orientation that should be producing it. So they route around it. They do this not from a lack of the orientation but from having it. The developer who declines to leave capacity idle, who finishes the committed slice rather than dropping it for someone else’s integration defect, who races their own work to done, is behaving exactly as a finishing-oriented person believes a finishing-oriented person should behave. They are wrong, but they are wrong in good faith, and they are wrong because of the orientation, not in spite of it.

The resolution is that the correct expression and the apparent betrayal are the same action seen from two distances. From close up, at the level of the local slice and the present moment, reserving capacity and pre-empting committed work and slowing to collaborate are all betrayals of finishing. From the distance of the unit of value the stakeholder actually cares about, they are the only behaviours that are finishing — because the unit was never the local slice. It was the cross-boundary thing, and finishing the cross-boundary thing requires precisely the actions that finishing the local slice would prohibit. The orientation is correct. Its correct expression is invisible from the position the person doing the work occupies, and what is visible from that position is something that looks like the orientation’s negation.

This is why naming the principle, though it is not nothing, is not enough. The principle can be held sincerely and still be misapplied, reliably, by the people who hold it most sincerely, because the misapplication does not feel like one. It feels like fidelity. The gap between holding the principle and expressing it correctly does not close when the principle is stated clearly, because the gap is not made of unclarity. It is made of the fact that, at the moment of every individual decision, the correct action wears the face of the wrong one.

A note on what was already known

It is worth observing that the effect underlying all of this has already been measured, carefully, by people with no stake in the present argument.

The research that produced the DORA findings established, across a large body of evidence and with considerable methodological rigour, that organisations which resolve defects of this kind quickly are more effective at delivery than those that do not. The finding is robust and is not in dispute here; if anything its rigour is what makes it usable. What the research attributes the effect to, largely, is the technical apparatus: continuous integration, deployment automation, the engineering capability set that lets a fix move from identified to resolved with little friction.

That apparatus is real and it does help. But it is the instrumented, visible, measurable case of something more general. What makes fast resolution possible is not, fundamentally, that a pipeline exists. It is that failure demand is sequenced ahead of committed work: the system is oriented toward finishing the thing of value rather than protecting the progress of its parts. A pipeline makes acting on that orientation nearly free, which is why the effect shows up so clearly where pipelines exist and why the pipeline gets the credit. But a pipeline-rich organisation oriented toward starting will let a cross-boundary defect rot regardless of how good its automation is, and a finishing-oriented organisation without much of a pipeline will resolve it anyway, more slowly. The orientation is the operative thing, and the apparatus is only the carrier it was measured through. So the principle this essay describes is not a speculation awaiting evidence; it is what the evidence already found, described in terms of the disposition rather than the tooling that made the disposition legible.

Where this leaves the reader

The leverage is real and it can be pointed at. Name the principle. Explain why finishing the thing of value precedes starting or completing its parts. Stand behind it when standing behind it costs something. An organisation that does this exerts genuine drag toward the orientation from which the necessary coordination emerges without anyone having to design it. This is not a small thing to be able to say, and constructing a vantage, whether the dedicated function that is the universal default or the distributed arrangement that is its less common alternative, is conspicuously not it. Either construction solves the half of the problem that can be solved by building something, and leaves the half that cannot.

But the pointing does not dissolve the difficulty, and an honest account has to end by saying so. Even where the principle is named and genuinely held, its correct expression in a cross-boundary context still presents, at the moment of each individual decision, as a betrayal of the principle itself. The orientation does not carry its own correct application with it. The person who holds it most sincerely is, at the decisive moment, the person to whom the right action looks most like the wrong one. That gap is not closed by clarity, because it was never made of confusion. It is made of distance: the distance between the slice in front of the person and the unit of value the slice belongs to, a distance that is invisible from exactly the place the work is done.

The quality that no team owns is not, in the end, a problem of vantage, though that is the part organisations solve. It is a problem of what finishing means when the thing being finished is larger than anyone’s ownership, and of the fact that the people most committed to finishing are the ones least able to see, in the moment, that the thing they are protecting was never the thing that needed to be finished.

The Quality No Team Owns was originally published in Beyond Localhost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Taken together, though, they constrain what can be drawn around that estate. A framework that asks an organisation to place every system, and therefore every team, inside exactly one long-lived container is asking for something the two observations may not permit. Whether they permit it is a property of the particular estate, and the striking thing about the framework that prescribes the container is that it never asks.

The mechanism

The Scaled Agile Framework publishes a procedure for deciding what its containers hold. It appears in the implementation roadmap as one of the critical moves, and it runs in six steps: identify the operational value streams; identify the solutions those value streams use or provide to customers; identify the people who develop and support those solutions; identify the development value streams that build them; add the people needed for the full business solution; realise the development value streams into Agile Release Trains.¹

Compressed, and the compression is faithful:

• Map the operational value stream.
• Assign the systems that support each of its steps to those steps.
• Assign people — Solution Trains, ARTs, teams — to those systems.

The framework distinguishes two kinds of value stream, and the distinction survives scrutiny. An operational value stream is the sequence of activities by which the business delivers something to a customer: fulfilling an order, providing a loan, admitting a patient. A development value stream is the sequence by which software gets built and supported. Building a system and running a business are different activities, and separating them is sound. Nothing in what follows disputes it.

What is worth noticing is where the axis changes. The portfolio is organised around value streams and funded through them. But the ART, the container that holds people, is described throughout the framework’s own material as aligning teams around a product or a related set of products, holding the capabilities needed to define, build, validate, release and operate one or more of them.² The value stream supplies the name. The system supplies the container. No rule is given for what to do when those two things want different boundaries.

When the coercion is free

It is worth being clear early that the mismatch often does not arise.

Where each system supports a step of one operational value stream, or several adjacent steps of it, and no other, step three costs nothing. The systems partition cleanly, the people who build them partition with them, the containers are well formed and the promised benefits are available. This is the picture the framework’s own figures show, and it is not a hypothetical case. It is the ordinary condition of a product organisation whose modules and whose customer journeys were designed in the same exercise. It is also the ordinary condition of the outer edge of many enterprise estates: channel applications, customer-facing portals, systems bought to serve one process and never asked to serve another.

A critique that treats every estate as broken is both false and easy to set aside by anyone whose trains are running. The question is not whether the mechanism can work. It is what happens as the condition under which it works is progressively withdrawn.

Relation and function

Step two of the mechanism records which systems support which steps of an operational value stream. Run once, it produces a map. Run across the several operational value streams a large organisation has, it produces an incidence: a record of which systems are touched by which processes.

That incidence is a relation. It may happen to be one-to-one; it may be many-to-one, with several systems serving a single process; it may be many-to-many, with systems appearing under several processes and processes traversing several systems. Where it is many-to-many, the picture in the figures fails in a second way. A system reached at the second step of a process, again at the seventh, and again at the period close is not a stretch of that flow. It is a node the flow passes through, as it does for the other processes reaching the same system from their own directions. Segments can be owned in sequence. Nodes cannot.

Step three requires a function. Every system must sit in exactly one container, and every person with it.

The conversion is lossless under one condition: the systems partition must refine the operational value stream partition. Set the incidence out as a matrix, systems as rows and operational value streams as columns, and the condition is that the matrix can be permuted into block-diagonal form. Where it can, the blocks are the containers and nothing is lost. Where a system appears under two processes, mass remains outside the blocks, and no permutation removes it.

Everything that follows is a matter of degree rather than a switch. A small residue is a tax on a workable structure. A large one makes the structure a fiction maintained alongside whatever is really routing the work. Where the crossover lies is a property of the particular estate and not a constant, and neither the framework nor this essay can state it. What can be said is that the framework offers no way to pose the question. There is no step at which the incidence is examined as a whole, and no artefact in the method that could hold it: the value stream definition template is per operational value stream, the development value stream canvas is per development value stream, and the figure that maps systems to steps is drawn inside one process. A practitioner who wanted the transposed view — take the finance system, ask which processes touch it — would have to invent the artefact, and would then have no step in the sequence to bring it to.

Trees and semi-lattices

Christopher Alexander set out the underlying structure in 1965, writing about cities rather than software.³ His subject was why deliberately planned cities feel dead where cities that grew do not, and his answer was a claim about the shape of the structures planners impose.

A collection of sets forms a tree, in his definition, if for any two sets in the collection either one is wholly contained in the other or the two are wholly disjoint. Team inside ART inside Solution Train is a tree in exactly this sense. He drew out the restriction the definition carries: within a tree structure, no piece of any unit is connected to other units except through the medium of that unit as a whole. Applied to a city, this is the assumption that the smaller elements within a neighbourhood belong together so tightly that they interact with elements elsewhere only through the neighbourhood they belong to. Applied to an ART, it is the assumption that a team’s work reaches other teams through the train.

Alexander’s case against the assumption came from Ruth Glass’s plan for Middlesbrough, which divided a town of two hundred thousand into twenty-nine neighbourhoods by locating the sharpest discontinuities in building type, income and job type. Having drawn them, she asked whether the units defined by the town’s actual social systems — the school, the post office, the youth club, the adult club, the grocer — fell inside the same boundaries. They did not. Nor were they disjoint. They overlapped. Alexander’s account of why is the sentence to carry across: nothing in the nature of those various centres requires their catchment areas to be the same, their natures differ, and so the units they define differ.

Nothing in the nature of a running system makes its boundary a process boundary either. Different natures, different units.

The more useful half of Alexander’s apparatus is the alternative he names. A collection forms a semi-lattice if, whenever two of its sets overlap, the set of elements common to both is itself a member of the collection. In the city, this says that where two units overlap, the overlap is itself a recognisable thing. His example is a newsrack that belongs both to the system of the traffic light and the pavement and to the system of the drug store and its entrance, and is a unit in its own right either way.

That supplies a test that can be put to any proposed structure: name the overlaps, then ask of each whether it is a unit. In the containment scheme under discussion, the intersection of two ARTs — the change that has to touch both systems — is not a unit. It has no owner, no backlog, no capacity, no cadence, no queue policy and no demonstration of its own. The tree axiom does not merely forbid overlapping containers. It forbids the overlap from having any existence at all.

One further point of Alexander’s is worth keeping, because it prevents the argument from becoming an accusation. His explanation for why designers build trees is cognitive rather than ideological. The mind reduces ambiguity by putting things in one category at a time, and a semi-lattice cannot be held in a single mental act where a tree can. The tree is what any designer reaches for under pressure to produce something graspable. That includes anyone making this argument.

What follows where the estate is connected

Consider what a shared system does to the incidence, rather than to any single container.

A system serving two operational value streams does not merely get claimed twice. It joins them. Take the systems and the operational value streams as a graph, with an edge wherever a process touches a system, and the smallest containers that can be drawn without severing anything are that graph’s connected components.

Not every shared system contributes to that joining in the same way, and the difference decides which cases are difficult. What matters is not how many processes reach a system but whether what they need from it differs. An identity service is reached by everything and is not a problem: every process needs it to do the same thing, so there is no variation for the system to absorb and the interface can be specified once for all comers. A system in that first position is a supplier, and a supplier relationship is not a containment problem. The same holds for a delivery pipeline or a cloud substrate. A master data platform sits in a second position. What the processes want from it does differ, and can conflict: finance, procurement and compliance ask for different attributes and different rules on the same vendor record. But the conflicts are all of one kind, questions of how data is structured, owned and kept correct, and one body of expertise can adjudicate them. What arises is contention over priority rather than incoherence of domain. A resource planning system sits in a third. The processes reaching it want different business logic, and that logic belongs to unrelated domains: procurement rules, payroll rules, revenue recognition. No single discipline adjudicates between them, because they are not the same kind of question.

The second and third positions drive the result. One master data platform and one resource planning system, each reached by most of the organisation, and the components merge until the estate is a single component. The only structurally correct container then holds the whole of IT.

It cannot be an ART. The framework’s own criteria for an effective train list fifty to a hundred and twenty-five people, focus on a holistic solution or a related set of products, long-lived and stable teams, minimised dependencies on other ARTs, and the ability to release independently.⁴ Those criteria are given flat, with no priority among them and no rule for the case where the first and the fourth cannot both be had. Where the estate is connected, they cannot both be had. Correct containment and the size limit are jointly unsatisfiable, which means every implementation on such an estate has already broken the containment condition. The open question is only where the breach was placed, and whether anyone wrote it down.

The framework does address the shared-system case, and its answer is to enlarge the container. Several operational value streams, it says, can often be served by a single development value stream that builds and configures the systems those processes need in order to function and to share common information; the worked example is an enterprise-wide resource planning system.⁵ The illustration is therefore drawn from the third position, the hardest of the three, which is worth pausing on rather than passing over. The framework is not avoiding the difficult case. It is answering it, and the answer is absorption: containment satisfied by making the container large enough to hold the coupling, which trades an external premium for an internal one and moves towards the size limit rather than away from it.

Where the pattern is filed matters as much as what it says. It appears among supporting value streams, alongside the annual audit and employee onboarding. The resource planning system in that illustration is serving internal administration, where the demand arriving from each process is thin and the domains held together are few — a system closer to the second position than the third, whatever its product name. The pattern is offered for the case in which absorption is cheapest. It then stands as the framework’s answer for the case in which it is dearest: the same class of system carrying order-to-cash and its neighbours, where each process brings its own business logic and its own domain.

Size is the visible cost of absorption and the smaller of the two. The larger one is that the container now holds several business domains. Whoever owns the enlarged system holds procurement, payroll and revenue recognition at once, or specialists in each share one codebase and one release calendar. The framework’s imported team topologies speak to technical depth — the complicated-subsystem team exists to contain deep specialist knowledge of a subsystem — and say nothing about breadth across unrelated business domains.

Stakeholders arrive with the domains. A train assembled by absorption has business owners whose mandates have no common ground, competing for one backlog, and there is no forum above them in which to settle the competition, because business owners attach to trains rather than to systems. The instrument the framework supplies for ranking assumes what absorption removes: weighting requires a shared frame in which the candidates can be compared, and a procurement change, a payroll change and a revenue recognition change have no common denominator beyond whoever argues hardest. What returns is a queue with several masters and no basis for ordering it, which is among the problems the alignment machinery was built to remove. Absorption satisfies the containment rule by reintroducing the condition the containers were meant to end.

An independent case study records the move being made. Researchers studying a Danish pension and insurance company through twenty-four interviews found that splitting pension and insurance into two value streams was discussed and judged extremely difficult, because of resource constraints and because very specialised people worked across both products; the two product groups were therefore put into a single joint train.⁶ That train came out at a hundred and twenty people across eleven teams, at the top of the permitted band. In the same organisation, a train assembled from many departments whose people did not share qualifications was judged unable to form full-stack teams and was built from component teams instead.

The second of those trains is the same cost arriving without anyone having chosen absorption: draw a container around a shared system and the breadth comes with it, whether or not the estate was ever connected enough to force the question. Absorption at least makes the cost deliberate. Ordinary shared ownership makes it incidental, and harder to see.

Why this lands on IT

The misalignment is not peculiar to enterprise IT. A product organisation whose checkout, returns and renewal journeys all traverse a shared pricing or subscription service has the same many-to-many map. What is peculiar is the absence of any axis that can be moved.

The clearest way to state it is by asking where the business process sits relative to the estate boundary. In product development, the process the product supports is on the far side of it. It is the customer’s process, running through the product rather than through the developing organisation’s own systems, and it therefore never becomes a cross-cutting concern of that organisation’s containers. One axis, and a tree is legitimate. In enterprise IT the process runs inside the estate. Order-to-cash traverses six systems the same organisation owns, funds and staffs, so it is a path through its own containment scheme and cross-cutting by construction.

Both axes are then fixed by parties other than the organisation drawing the boundaries. The system axis is imposed by production: one deployment authority, one release calendar, one schema owner per running instance, enforced whether or not anyone organises around it. The process axis belongs to the business, is frequently constrained by regulation or contract, and is further constrained by what the vendors embedded. A product organisation facing the same misalignment owns the internals on both sides and can move a rule from the journey into the service or back. That option is not available here.

It is worth separating three couplings that this discussion runs together, because a standard response addresses the wrong one:

• System to system. Technical dependency between software systems. This is what architectural runway, decoupling and independent deployability target.
• System to operational value stream. One system serving several business processes. This is the relation that decides whether containment is possible.
• Entity and data. Shared master data and invariants spanning processes, which is why the second relation persists.

The advice to invest in architectural runway is sound advice about the first. It does not touch the second. Decompose the resource planning system into a dozen services and order-to-cash now traverses a dozen nodes instead of one, each still touched by several processes. The matrix grows without coming any closer to block-diagonal form: the residue is preserved and the number of things needing allocation rises. Whether that is better or worse for coordination is arguable; it is not progress on containment, because containment was never a system-to-system problem.

Where the second relation could be reduced, the price is the third. Nobody consolidated onto an integrated resource planning system by accident. One version of the master data, one close, consistency across processes. The coupling is the feature that was purchased. A vendor contract is legitimately part of the value streams of procurement, of finance, of operations and of compliance, and those four do not hold four copies of it. They hold four views of one record, with one identity, one lifecycle and one authoritative state. Processes are partitioned by purpose: hiring, paying, procuring, auditing. Systems and data are partitioned by entity: vendor, contract, employee, product. Neither refines the other, because they are cut on different things, and any tree has to choose one and leave the other cross-cutting.

This also explains why the step-two map of the Scaled Agile Framework cannot show the difficulty. What it records is usage and flow — which process touches which system, in what order, with what delay between steps. That is what a value stream map is for and it does it well. Coupling of the third kind was never within its remit: shared master data, an invariant spanning two processes, a common period close produce no edge on it, because nothing in the instrument asks for one. The defect is not in the mapping. It is in treating the resulting artefact as a sufficient model of coupling on which to draw permanent organisational boundaries. The Lean tradition never asked a value stream map to carry that load.

What is not known before the commitment

The guidance may yield a structural setup that cannot be sustained. Where the incidence between systems and operational value streams is sparse it will not, and where it is dense it will. Most estates of any age sit between those poles, and where a particular one sits is what decides the matter.

The framework offers no way to establish, before the commitment is made, which case a given estate is in. The workshop draws boundaries while the property that determines whether boundaries can be drawn goes unnamed, the roadmap places the first train’s launch at the end of that same exercise, and correction waits for a later step reached after several more trains are running.

So the structure is committed to without the information that decides whether it will hold. And when it does not hold, the account offered is that identification was done badly. That account is always available, it fits every failure, and nothing observable separates a boundary drawn poorly from a boundary that could not have been drawn well. Alexander declined to sketch the semi-lattice city, on the grounds that overlap alone gives no structure and he could not yet say which overlap was the right one. The comparable restraint is to notice that the question was never put, and to leave it there.

¹ Scaled Agile, Inc., “Identify Value Streams and ARTs”, scaledagileframework.com, last updated 10 February 2021. The current framework site places this article behind a login; the version cited here is the Internet Archive capture of 18 January 2022.

² Scaled Agile, Inc., SAFe Explained: Succeeding with Lean and Agile at Scale, April 2025, pp. 11 and 21.

³ Christopher Alexander, “A City is not a Tree”, Architectural Forum, April and May 1965; reprinted in Design 206, 1966, from which the passages here are taken.

⁴ The five criteria appear together in the identification article cited above; the range of fifty to a hundred and twenty-five people is repeated in SAFe Explained, p. 21.

⁵ Scaled Agile, Inc., “Development Value Streams”, scaledagileframework.com, last updated 18 March 2021, Internet Archive capture of 8 December 2021.

⁶ Abheeshta Putta, Maria Paasivaara and Casper Lassenius, “How Are Agile Release Trains Formed in Practice? A Case Study in a Large Financial Corporation”, in P. Kruchten et al. (eds.), XP 2019, LNBIP 355, Springer, pp. 154–170, doi:10.1007/978–3–030–19034–7_10. The wider transformation is reported in the same authors’ “SAFe transformation in a large financial corporation”, Empirical Software Engineering 29:27, 2024, doi:10.1007/s10664–023–10420-w, whose discussion of external validity names tightly coupled legacy systems among the conditions under which its findings would transfer.

The Estate Is Not a Tree was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

An earlier essay, The Shape of the Work, diagnosed the wrong unit and named the right one: the piece that belongs on the board is a whole a customer would value, not a slice cut to one specialist’s contribution. That essay assumed the work would then decompose into wholes of a workable size, and admitted the case where it does not, where a deliverable would “resist any clean cut, and there the demand strains.” This is the essay for that strain. It is the advice that the diagnosis was owed: given a whole too big to build at once, how do you cut it, and what tells you that you have cut it well?

What this work is

The advice depends on the kind of work being cut, so it is worth saying plainly what that is. The work this essay concerns is creative in a precise sense, borrowed by the earlier essay from the psychology of creativity: a response is creative to the degree that it is at once an original and fitting answer to the problem, and that the problem admits no settled path, so the answer has to be discovered rather than produced by running steps laid down in advance.¹ Most of what a product team does in building software is of this kind. Two properties follow from it, and the whole of the advice rests on them.

The first is that value does not add up from the parts. The valuable thing is the answer to the whole problem, and the parts have to be worked out against one another to reach it, the data model learning from the interface, the interface forcing the logic to change. No single part carries the value, because the value exists only once the parts compose. Call this non-additivity.

The second is that the route is discovered as the work proceeds. Because there is no settled path, a part cannot be finished in confident ignorance of the others. What one part turns out to need may overturn a decision another part has already made. Call this non-separability.

The earlier essay drew the line these two properties fall on. Work that splits cleanly is additive and separable, work with a fixed path and independent parts; creative work is neither. That line matters here because everything below holds only on the creative side of it. Where a path is fixed and the parts are independent, the ordinary advice to cut small and cut freely is right, and this essay does not reach that work.

The word that sizes and ranks

Return to the rule that went quiet. “Valuable to a customer” is asked to do two different jobs, and it is competent at only one. One job is ranking: deciding whether a piece is worth building, and in what order against everything else competing for the team’s time. The other is sizing: deciding what the piece is, where it begins and ends, how the large thing is carved into smaller things. The familiar checklists fuse the two. INVEST asks a slice to be independent, valuable, and small in a single breath, as though worth and size were one property read off one measurement.² The Kanban Guide goes further and builds value into the unit itself: a team defining its workflow must first define the units of value moving through it, and those units of value are what it calls work items. Value is written into the definition of the thing that moves.³

Value is a question for ranking, not for sizing. Even in ranking it is narrower than it looks. One can say that a thing is valuable, argue for it, and stand behind the argument. What cannot be had is the quantity.⁴ How much value a thing carries is unknown until it exists and reaches a beneficiary, and any figure produced before that is an estimate wearing the clothes of a measurement. To call a piece valuable is to claim that a world with it would differ, for some customer, from a world without it. The claim can be made and defended; experienced product people make it constantly; but it rests on a reading of customers that is external to the work, exposed to bias, and often wrong, and the comparison it invokes is with a world that will never exist to be checked against. To lean the cut on that signal is to import all of its difficulty into an activity, sizing, that ought not to need it. And it under-determines the cut even when the reading is perfect, because more than one carving of the large thing yields pieces a customer would value, and value, having certified them all, falls silent on which to prefer.

So the two jobs come apart, and a question is left standing once value steps back from sizing: on what does the cut run, if not on value?

What flow wants, and what stops it

There is a force with a clear answer, and for a while it looks like the whole answer. Flow wants small. Smaller pieces move through a system faster and more predictably, integrate with less pain, carry less risk each, and return their answer sooner; the case for reducing batch size is old and well made. And the last structural reason to resist it has lately fallen away. When a deploy or a release was expensive, batch size had a natural floor, because it was not worth shipping something tiny. With continuous integration and automated pipelines the cost of a release approaches zero, and the floor drops out. Nothing inside the logic of flow now stops the pieces getting smaller without limit. Divide, and divide again.

One thing stops it, and it comes from outside the logic of flow. A piece can be made so small that it is no longer a whole, and a piece that is not a whole cannot bear value, in the strict sense that value cannot even be predicated of it. The question “is this valuable, and how much” gets no small answer below the whole; it gets no answer at all, because there is nothing there of the kind value attaches to. Wholeness is the floor the gradient runs down to and must not cross.

Cross it, and the harm is not merely that nothing valuable has shipped. A finished piece that is not a whole is a liability, in two ways a flow ledger cannot see. The first: until its siblings arrive it is dead weight in the product, code that runs and does nothing, waiting for the parts that would give it a point. The second is worse, and is the one the cheap release cannot rescue. To finish a part of creative work ahead of its siblings is to freeze a decision before the work that would inform it has been done. Because the route is discovered, that decision is a bet placed in the kind of work where early bets are most often wrong, and when a sibling later forces a change the finished part is not merely idle but rebuilt or discarded. None of this is gated by deployment. A part called done in a queue, or sitting behind a feature flag in production, carries the same frozen decision whether or not it has shipped, and a release that costs nothing changes none of it.

This is where flow’s own instruments mislead. Throughput, cycle time, a burndown, each records the finished part as done, off the books, a success. It is in fact an open, risk-bearing commitment wearing the costume of a completed one. The measure does more than fail to see the value that has not arrived; it files a liability as an asset. Flow’s economics, inherited from the manufacture of separable things, has a term for a dependency as a cost to schedule around and no term for non-separability as the reason a finished part can be an error. That blindness is why flow, left to steer the cut on its own, will shrink the unit straight through the floor.

The criteria for a whole

If the floor is wholeness, the practical question is how a team recognises a whole without having to price it. It needs a property that is structural, checkable at the bench, and does not smuggle the value counterfactual back in. That property is purpose. A piece is a whole when it is directed at an aim that a receiver, someone outside the team, would recognise as an aim. A password reset has a purpose. A shopping basket has one: assemble what I mean to buy. A schema migration has none that a user would recognise, only one the engineer would. Purpose is what “value” was reaching for at the moment of the cut, and it is the safer word, because a thing serves a purpose whether or not that purpose is worth much, and worth is the question sizing is trying to keep out.

Two conditions keep the property honest, and both are places it can quietly fail.

The first: the purpose must be recognised by a receiver the cut did not create. Everything is purposeful in some frame; the migration has a real purpose to the person writing it. What denies it wholeness is that no receiver outside the work recognises a purpose in it. The receiver may be a user, or a downstream service that would consume the output for its own ends whether or not this particular cut had been made. What does not count is the next stage of the very thing being split. If “step one is received by step two” is allowed to certify step one, the old layer-slice walks back in through the side door, the backend “receiving” the database, and the diagnosis is undone. The receiver has to be someone the split did not invent.

The second: purpose is directedness, not worth. This is the guard most likely to give way, because “purposeful” sounds like “worthwhile” in a way “receivable” did not. The basket has a purpose and, on its own, is worth almost nothing. That is not an embarrassment for the account; it is the account’s central claim in a single instance. That a piece is purposeful means one can ask what it is for, which is to say that value is predicable of it. Whether it is worth doing is a separate argument, and it belongs to ranking. How much it turns out to be worth is not an argument at all, and no one has it in advance. Purpose is direction; worth is magnitude, and magnitude arrives late or not at all. Hold the two apart, or “purpose” quietly becomes “value” again and the cut is back where it began.

From purpose, three familiar tests follow, not as separate hurdles but as faces of the one property. A purposeful piece is receivable: some receiver the cut did not create can, given what already exists, achieve the aim, however narrow, without waiting for a sibling still in progress. It has a journey: it passes through conditions defined by its progress toward the aim, understood, built, checked, ready for the receiver, rather than the inward states of the workshop, written, merged, deployed, which every fragment has too. And on completion it returns a signal, an outward one, that the aim has been met and not merely that the code integrates. The Agile Manifesto reaches for the same thing when it asks for working, valuable software delivered early and often; the work here is to say what “working” and “valuable” have to mean at the moment of the cut.

Now the hard part, the one that makes “receivable” feel slippery. Purpose is satisfied at more than one scale. A basket has a purpose; so does the checkout that follows it; and only both together serve the purpose the business cares about, that a customer can buy. Point at any level of the work and something answers to “purpose,” which is why an executive, a product owner, and an engineer will each locate the whole at a different altitude and each be partly right. The mistake is to think the tool’s hierarchy settles it. Epic, feature, story is a nesting of purposes within purposes, a means-and-ends structure the organisation adopts for planning, and asked to certify wholes it is a false friend. Sometimes a story is a thin whole; sometimes it is a fragment the tool has dressed up to look like a deliverable. The levels record a relationship somebody asserted; they do not test it. The criterion does not pick a level. It certifies a whole at whatever level a receiver’s aim comes to rest, and leaves the levels to hold what the criterion has certified, which is a job they do well and one this essay returns to.

The basket makes the trap concrete. Is releasing the basket alone a whole? It depends on a receiver, and on which one. If some real user’s aim ends at a basket, the shopper assembling a list to buy later or on another channel, then the basket is a thin whole. If everyone who fills a basket means to buy now, the basket alone leaves them mid-aim, and it is a fragment that must travel with checkout. The test is not whether the piece does something, but whether some receiver’s purpose terminates at it. Delete the pieces you meant to ship alongside it, permanently, and ask whether anyone outside the team is left with something they would recognise as achieved. If yes, a whole; if what remains is inert, or half-finished from the receiver’s side, a fragment. The test is asymmetric in a telling way: checkout presupposes a basket to act on, while the basket does not presuppose checkout. The two are not the mirror image they first appear, and that the criterion can tell them apart is a sign it is doing work rather than waving.

Two things fall out of taking altitude seriously. The executive’s version of the question, whether the whole business capability is worth building, was a ranking question all along, wearing the clothes of a sizing question; naming the receiver sends each altitude’s question to the room where it belongs. And, more useful day to day, the unit you size and flow need not be the unit you release. Where basket and checkout are each wholes, you may size them apart, let each flow on its own, and still hold their release together into the larger purpose, buying, that neither completes alone. Sizing carves; releasing groups; and the split between sizing and ranking, extended one turn, is what lets the two happen at different grains.

There is a check a team can run with no customer data at all, worth having because engineers sit furthest from the customer. If a piece is a whole, a business person in the room can name the aim it serves and for whom. If only an engineer can see the accomplishment in it, it is a fragment. The Manifesto’s call for business people and developers to work side by side, day to day, reads in this light less as a virtue to profess than as the field reaching for this very boundary without a name for it: daily contact was the mechanism found for keeping a unit jointly legible, in the absence of a test for when it had stopped being so. The test is the aim. Ask what it serves and for whom; a shrug, or an answer that names only a technical step, is the alarm.

Purpose settles what a piece is for. It does not settle whether the piece can be finished on its own, and that is a separate demand, the one flow’s economics could not see. A whole must be able to reach done without freezing a decision that unstarted sibling work could still overturn. A piece that fails this is an orphaned commitment: purposeful, perhaps, and receivable, perhaps, and still a bet locked in ahead of the discovery that would settle it. This is the frozen decision from earlier, turned from a warning into a criterion on the cut. It is not a new observation; the earlier essay already noted the piece completed before it was understood and rebuilt once a sibling forced its hand. What is new is using it to size: a cut that severs two parts which still have to learn from each other is a bad cut, however purposeful each part looks alone.

The two demands do not bite in the same way, and it is worth being straight about that. Purpose is a floor. Go beneath it and the piece cannot bear value at all, has no receiver, returns no signal, and there is no way to manage around the fact. Nothing is bought by crossing it, so nothing is traded. The no-orphan demand is a gate of a different kind. It can be passed, and passing it buys something real: across two teams it buys parallelism and the cycle time that comes with it, and even inside one team it buys smaller pieces, verified earlier, each carrying less risk than the whole would. What it costs is a liability taken on, the frozen decision and the coordination that follows. So the demand is not a line that cannot be crossed but a price that must be paid and, more to the point, carried on the books. This essay’s complaint against the flow ledger was that it files a liability as an asset. A cut that orphans knowingly, with the liability recorded and honoured, is a trade made in the open. A cut that orphans without noticing is the same liability, mis-filed.

The two demands are independent, and the basket shows why. Checkout has a clear purpose and passes the first test, yet shipped without a basket to operate on it orphans a commitment and fails the second: purposeful, and still a bad cut. The reverse case exists too. A feasibility spike or a structural refactor orphans nothing and stands cleanly on its own, passing the second test, while serving no aim a receiver would recognise and failing the first. Both cases are real, so the two criteria are not two names for one thing. They catch different faults, and only the plain fragment, the internal handoff, fails both at once.

Together the two criteria fix the bottom of the structure, and the bottom is not negotiable. The smallest thing a user would recognise as having a purpose is the lowest a cut may ever go. Orphaning does not enter here, because orphaning is a price and this is a floor: no coordination, however diligent, redeems a piece that no receiver can recognise. What counts as user-recognisable varies by product, so the floor is not a fixed size; but the rule is fixed, and no organisational preference may push a piece beneath it. Above that bottom floor the hierarchy is the organisation’s own to build. Whether it runs two levels or four, what it names them, how it maps them to its planning, is its business and driven by concerns this essay has no view on. The one demand the essay makes of the upper levels is structural: each must have a purpose-floor of its own, set and shared, and the items at that level should tend toward that floor without dropping beneath it. That tending toward a floor is what makes a level coherent, its items comparable in grain rather than an epic sitting beside a story.

The failure here is easy to miss, because the tool hides it. It rarely looks like an epic and a story side by side, visibly mismatched. It looks like a board on which everything is called a story, and one of those stories is an epic in all but name, dressed in the type its neighbours wear. The label asserts that the item sits at the story floor; nothing tests the assertion. This is the hierarchy doing again what it did earlier, recording a claim about a level rather than checking one, and the uniformity of the names is what makes it invisible. A team can hold a shared floor in principle and ignore it in practice for months, because the board reports no discrepancy: every card says story, so every card must be a story. The type name is a claim, and like any claim it can be false.

Where the upper floors sit, the essay does not say, because it cannot. It depends on the work and on a dozen properties of the organisation, and any formula offered here would be false precision. What can be said is smaller and honest: a level needs a shared sense of its floor, and you can tell when it lacks one, because the items at that level come out wildly unlike in size. Read the sizes, not the labels, since the labels are the thing that hides it. That is a symptom to read, not a number to hit.

When there is no clean cut

There remains the case a team meets most often, and the one an essay of advice owes an answer to. A whole serves a clear aim and is still too large to be carried in any reasonable time. Every cut that clears the purpose floor orphans something; there is no clean split to be found. What then? You cut anyway, and you take the cut that orphans least. Basket and checkout, knowing each has to learn from the other. This is not a defeat, and it is not a last resort either. The floor has done its work by ruling out the cuts that would have produced fragments; among the cuts that remain, orphaning is a cost to be weighed, and a whole too large to build is itself a cost, often the larger one.

What the team owes in return is to stop treating the pieces as independent merely because the board now shows two items. They are one commitment carried in two, and they should be managed as one. Keep them close in time rather than letting the second drift behind unrelated work. Hold the decisions in the first loosely, reversible where reversibility can be bought cheaply, because the second may well overturn them. Let each inform the other while both are still in flight, which is the whole point of not deferring the second. And release them together. Deploy separately if the pipeline makes that easy, but do not put half a purpose in front of a receiver and call it delivered; sizing carved the work into two, and it did not thereby carve the aim into two. The pair travels as one until the aim is met.

That is the easy version, where both pieces sit with one team. The harder version is also the more common reason for making the cut at all. Within a single team the two pieces will mostly be worked in sequence anyway, so the gain is the ordinary one of smaller batches; across two teams, two boards, perhaps two product owners, the split buys parallelism, and that is a reasonable thing to want. Sometimes the split is not chosen at all but inherited, the boundary already drawn by how the organisation is arranged and which team owns what. That is worth separating from the case at hand. Where an existing boundary happens to fall between two purposes, the advice below applies unchanged. Where it falls through the middle of one, so that neither side of it can name an aim of its own, the result is not a cut to be managed but a boundary worth questioning, and the criteria have not been satisfied merely because the organisation chart says the work has to go that way. Chosen or inherited, the cut across teams is where the cost stops being incidental and starts being real. Everything that made the one-team advice nearly automatic depended on the people holding both decisions sitting together and talking without having to arrange it. Across a boundary, none of that is free. The learning that has to pass between the pieces now has to be deliberately arranged and kept up, not once at the split but for as long as both are in flight. That is the price of the parallelism, and it should be paid knowingly rather than discovered late.

Two boards make the commitment invisible in a way one board does not. Each shows a purposeful item moving cleanly through its states, and neither shows that the item is half of something. Two product owners make it worse, because the pieces can now be ranked apart: one half can be deprioritised, deferred behind other work, or quietly dropped while the other proceeds, and no board in the organisation will report that an aim has been stranded.

The first move against this is to stop the relationship being invisible, and it is a cheap move. Link the two items to each other. Assign them to the same release. Where a work-item hierarchy already exists, and in most organisations one does, put them under a common parent. This is the hierarchy’s proper use, and it is worth saying so plainly after the warning earlier. The hierarchy is not a device for finding wholes; it cannot tell a team where a whole begins and ends, and a team that reads its levels as an answer to that question will be misled. What it is good for is the job it is being asked to do here: holding the relationships between wholes once the cuts have been made, recording that these two items answer to one aim and that this aim sits within a larger one. Used that way it costs nothing to adopt, because the structure is already sitting there, and it earns its place in the tool rather than merely occupying it. The particular mechanism matters less than that the relationship is written down somewhere both boards can see, rather than living in the memory of whoever made the cut.

Recording it is necessary and it is not enough. A link that nobody honours is a failure with better paperwork. If the decomposition was made consciously, in the way this essay has described, then the decisions taken downstream have to honour what the decomposition established. Ranking has to keep the pair together rather than letting one half win an argument the other loses. Scheduling and sequencing have to bring them into flight near each other rather than letting a quarter separate them. Collaboration across the two teams has to be arranged, because the learning that passed for free inside one team does not cross a boundary by itself. And the people making those decisions have to know the relationship is there and be willing to defend it, which in practice means having the standing to refuse a reasonable-sounding request to advance one half and leave the other.

There is a scheduling problem underneath this, and it is sharper than it first looks. The pieces have to be released together, so what matters is not that they start together but that they are ready together, and two teams starting on the same day will not arrive on the same day. They have different cycle times and, more to the point, different spreads. So the pieces should be started with an eye to converging: the slower or more variable of the two begun earlier, the difference in their distributions taken into account rather than assumed away. Here the flow metrics that were misleading earlier do honest work. Cycle time and its spread say nothing about whether a piece is a whole and nothing about what it is worth, which was the complaint against them, but they are the right instrument for asking when two pieces are likely to converge. The measures were never wrong; they were being asked a question they could not answer. This is a question they can. It still yields a probability rather than a plan, and the pair can miss, which is one more reason the relationship needs to be visible: when one half arrives early, the board has to show that arriving early is not the same as being done.

This lands on a decision that a different essay, on steering by value, argued was the only one a team really controls: when to start something.⁵ Everything downstream of the start is subject to a value nobody can quantify and to a route nobody can foresee, but the start is a choice made in the present with full knowledge of what it commits. What the orphaned pair does is spend part of that choice. A start that has to be timed against another team’s arrival is no longer a free expression of local judgement; it carries a dependency, and the judgement that decides it is answerable to something outside the room.

That is tolerable when orphaned pairs are occasional. It is a different situation when they are the norm, and in many organisations they are, because the work arrives in wholes too large for one team and the cut across teams is the standard move rather than the exception. Then most starts are negotiated against someone else’s timing, and the one lever the team held has been substantially spent before it reaches them. The right conclusion in that case is not that the team should get better at aligning starts. It is that the cuts are orphaning too much, and the alignment overhead is the bill arriving for it. A team that finds nearly every start entangled is being told something about its cuts, if anyone is listening.

All of that is cost, and it belongs on the same ledger as the orphaning itself. The split bought parallelism; the price is a link to maintain, a constraint on two rankings, two starts timed to converge, a collaboration to arrange, and someone with authority paying attention. Set against a whole too large to carry, the trade is often worth making. It is worth making with the price named, because the alternative is to take the parallelism now and meet the bill later, when one half has shipped, the other has slipped, and the aim that justified both is still not met.

Counting what flows

Sizing this way quietly repairs a measure that is usually broken. If every item that flows has passed the two criteria, then each item is, by construction, a bearer of potential value, a purposeful whole. Counted, they stop being a tally of tasks and become a count of bets placed: things capable of paying off, put in front of beneficiaries who can respond to them. The count says nothing about how much any of them was worth, and nothing about the total; the magnitude was never available and does not become available by being counted. What it supports is a weaker claim and a real one. Where each item is a genuine bet, more of them reaching beneficiaries in a given period means more chances for some to pay off, which is the only sense in which a team can say it delivered more.⁶ Raise the count of fragments and nothing follows at all, because a fragment is not a bet. The criteria are what make the number mean anything.

The count is trustworthy only within a level, and the per-level floor is what makes it so. A process-behaviour chart on throughput assumes the things counted are roughly comparable; the similarity of items at a level, their tending toward a shared floor, is what supplies that comparability. Count within a level and the units are alike enough for the chart to mean something; mix an epic in among stories and it is not. It is tempting to reach one step further and claim the value itself falls in a band, that most items cluster around some typical worth, and that claim should be resisted. It smuggles the counterfactual back in, and it is untrue in any case, since realised value across wholes is wildly dispersed, a rare item worth a hundred ordinary ones. That dispersion is also why the count matters in the way just described: when most bets return little and the occasional one returns a great deal, the number of bets placed is what governs the chance of catching one. The band that is real is a band of size, produced by the floor. The band of value is a mirage.

Two rooms, two times

Separating sizing from ranking does more than clarify a criterion; it lets the two activities come apart in practice, in who does them and when. Sizing, running on purpose and wholeness, is something a team can largely do itself, at the bench, with a product person on hand to confirm that an aim is recognisable. It does not need the room to hold a settled view of what any piece is worth. Ranking, an argument about what to do next under a value nobody can yet quantify, can happen later, in a different room, with different people present, some of whom took no part in the sizing. A team sizes a sprawling feature into a set of wholes on the Tuesday; a product owner convenes the argument about which of those wholes to do first, and against what else, on the Thursday, perhaps with stakeholders who could not tell a good cut from a bad one and have no need to.

The boundary is not a wall. A team will often want a product person present while sizing, because judging whether an aim is receiver-recognisable is easier alongside someone who knows the receiver, and the naming of wholes shades into the beginning of ranking. The claim is one of leaning: sizing leans to the team and its criteria, ranking to those who hold the customer counterfactual. Even as a lean it relieves a familiar strain. The demand side no longer has to collapse to a single point at the moment of sizing, because sizing does not need the demand signal at all; only ranking does. The product owner stops being the bottleneck through which every decision about every piece must pass, and becomes, more modestly, the person who owns the ranking once the wholes exist. With one standing exception, from earlier: where a cut has left two pieces that need each other, their rankings are not free to drift apart, and the relationship has to be recorded somewhere the ranking can see it.

Where it holds, and where it breaks

It is worth turning the essay’s own scrutiny on itself, since it has spent its length prescribing. Two limits bound what has been claimed.

The first is the scope marked at the start. All of this holds for creative work, work that is non-additive and non-separable, and only there. Where a path is fixed and the parts are independent, a part can carry a purpose of its own rather than borrowing one from the assembly, parts can be finished in any order, and the gradient may run down as far as it likes; the small parcel is then the right unit, and none of the criteria above earn their keep. A team that applies this account to routine work of that kind will tie itself in knots defending a wholeness that does not matter there. The advice is for work whose answer must be discovered, and claims no more ground than that.

The second is the case the criteria expose rather than solve, the one the earlier essay set aside. It is the harder cousin of the too-large whole met earlier. There, every available cut orphaned something and the answer was to cut anyway and manage the pair. Here, no cut leaves anything a receiver could take at all. Some deliverables are a single sprawling whole whose only purpose lives at the coarsest level, and which admits no purpose-floor beneath that level: cut it anywhere and every piece is a fragment, received by no one until the whole is done. The criteria do not dissolve such a thing; they diagnose it. They tell the team there is no good cut, which is worth knowing, because the alternative is to make a bad one and let the flow ledger call it progress. What to do with an irreducible whole, whether to build it as one long-running item and carry the risk, or to hunt for a receiver at some altitude no one had thought to look, is a real question this essay leaves open, because the honest answer is that the criteria mark the boundary and do not cross it.

What a team does differently on the Monday, then, is small enough to say in a breath, though none of it survives being separated from the reasons. At the moment of the cut it stops asking what a customer would value, which is a question about worth and belongs elsewhere, and asks instead what aim each piece serves and for whom, where the whom is somebody the cut did not invent. It tests the answer by deleting the siblings and seeing whether anyone outside the team is left with something they would recognise as achieved. It prefers, among the cuts that pass, the one that leaves the fewest decisions frozen ahead of the work that would inform them. When no such cut exists it takes the least bad one and says so, records the relationship where both boards can see it, times the starts so the pieces converge, and releases them together. It counts what it finishes within a level and not across levels, and it asks of that count only what a count can bear. And it does none of this for work whose path is already known, where the parts are separable and the small parcel was always the right unit.

Underneath all of it is a single reordering. The customer’s value was never the thing to cut on; it was the thing to bet on, and asking it to size the work was putting a question about worth where a question about form belonged. Sizing runs on purpose, and purpose has a floor, the smallest thing someone outside the room would recognise as done. Flow will take the work down toward that floor, and should. It is the floor’s job, not flow’s, to say where down ends.

¹ The two conditions are drawn, as in The Shape of the Work, from Teresa M. Amabile, The Social Psychology of Creativity (New York: Springer, 1983), p.33. Amabile characterises a creative response; the conditions are borrowed here as a test for a kind of work, which extends her account rather than restating a claim she makes.

² Bill Wake, “INVEST in Good Stories, and SMART Tasks”, XP123, 17 August 2003, where the acronym was introduced; taken up the following year in Mike Cohn, User Stories Applied (Addison-Wesley, 2004).

³ Daniel Vacanti and others, The Kanban Guide (kanbanguides.org, May 2025), on the Definition of Workflow, whose first required element is a definition of the units of value moving through the workflow, those units being what the guide calls work items.

⁴ On why the quantity is not there to be read off, and what is left to steer by once that is accepted, see Steering by Value: The Signal That Isn’t There.

⁵ On the start as the decision a team holds when the others have been taken away from it, see Steering by Value: The Only Decision You Control.

⁶ On why the payoff is asymmetric, so that placing more bets is worth more than reasoning harder about any one of them, see Steering by Value: You Can Kill a Bet, Not Confirm One.

The Floor of the Work was originally published in The Academic on Medium, where people are continuing the conversation by highlighting and responding to this story.

The arrangement worked. The new team got their compiler. But during the design phase something kept happening. They would work out how to accommodate the language extensions and submit the proposal to the original team for review, and in several major cases the original team found that the solution made no use of facilities that were already there in the structure of the existing compiler. Those facilities were not obscure. They were discussed at length in the documentation the new team had been given. The proposals instead added to the structure from outside, in the form of patches that destroyed its power and its simplicity. The original team could see these cases immediately, and could propose simple solutions that sat entirely inside the existing design.

Ten years later, after the compiler had passed to other programmers in the same organisation without the original team’s involvement, someone from that original team looked at what had become of it. The original structure was still visible. It had been rendered completely ineffective by amorphous additions of many different kinds.

Everything that could be written down had been written down. It did not transmit. So what was the original team holding?

What the Text Does Not Contain

Open any codebase of consequence and look for the file that states its decomposition. There is not one. There are names, directory layouts, import graphs, conventions that most of the team follow most of the time, and perhaps a diagram that was accurate at some point. None of these is the shape of the system. They are the particulars from which the shape is read.

Michael Polanyi gave the general form of this relation.² We recognise a face without being able to say what makes it recognisable: the set of the eyes, the line of the jaw, the proportions between them. We are aware of those particulars, and we are attending, through them, to the face. What we cannot articulate is the particulars. What we have instead is the face, which appears on no list of them.

The shape of a system sits in that relation to its code. You attend from the names and the call sites and the module boundaries to the shape, and the shape is what you then reason with. It is not recorded anywhere, and this is not an oversight that better tooling would fix. The shape is produced by an integration that a reader performs. Until someone performs it, the shape exists in nobody.

David Parnas made the same point from the other direction thirteen years earlier.³ Comparing two very different decompositions of the same system, he observed that both could produce an identical running program. The algorithms might be the same. The compiled result might be the same. What differs is not visible in the thing that runs, because the runnable form is only needed for running; the other forms are what you use for changing, documenting and understanding. Which means no test tells you your decomposition is wrong. Nothing checks this for you.

Return to the new team with that in hand. They were not short of documents. They read the same text the original team had written, assembled a different shape from it, and then reasoned correctly from the shape they had.

Built by Deciding

The two teams differed in one respect. One of them had built the original compiler. Everything else, the text, the annotations, the design discussion, the direct access to the people who wrote it, the other team had too.

Building is a sequence of decisions, and a decision has a property that reading does not. When you decide, you form an expectation and then find out what you got. The gap between the two is information, and it is information nobody else can receive, because the expectation was yours and it was never written down. A reader of the finished artefact gets the result without the expectation, which is to say a proposition rather than a discrepancy. Do this a few thousand times over the life of a system and you have a great deal that the artefact cannot supply.

Naur’s word for what a modification demands, first of all, is a confrontation between the existing solution and what the change requires. The word is well chosen. Something has to be held up against something else, and one of the two things is not in the repository.

This has a consequence worth stating once. Code you did not decide is inherited, and the ordinary difficulties of working on somebody else’s system apply, whoever or whatever wrote it. The condition that defines a legacy system is not its age. It is that nobody now working on it holds the shape, and a system can satisfy that condition from its first week.⁴

What Turned Out to Matter

Knowing what the parts are for is one face of holding the shape. The other is knowing what has already been pushed against it and did not go in.

Nobody holds the history of a system. Not the people who built it, not the ones who inherited it, and not any conceivable reader of its records. Three years of a mid-sized system is more decisions, incidents, arguments and reversals than any mind can carry.

What a senior engineer carries is a paragraph. We tried splitting that module around two years ago. It failed because the two halves kept needing the same data and we never found a clean line. Then the team that owned the second half was reorganised away partway through. By the time both of those were clear, the half-finished split was worse than either version we had started from. Four sentences covering a year.

That paragraph is not a summary of the records. Nobody sat down with the tickets and condensed them. It is a residue, and it has a specific history.

At the time, all hundred things looked like candidates. The coupling between the two halves was not visible from either side. The team was intact and nobody expected it to move. What puts these into the paragraph and leaves the other ninety-odd out is that later events said so, and nothing available at the time could have said it. Then the selection reopened. Something the following year turned out to bear on the same decision, and the paragraph was revised to carry it. It will reopen again the next time somebody proposes something adjacent. The residue is the current state of a selection that has been made repeatedly, each time in the light of what had happened since.

Which inverts the way capacity usually gets discussed. The head’s inability to hold everything looks like the handicap here, the reason we need artefacts at all. It is also what forces the selection, and the selection is where the judgment lives. Remembering less, correctly, is the skill, and the correctness was bought by having been wrong repeatedly.

This is worth separating from something it resembles. A system that can hold the whole history in view can produce a summary of it on demand, tailored to whatever question you ask. That is a different operation from what the senior did. Summarising is compression against a current query. The paragraph is compression against a long sequence of outcomes, each of which revised what the previous compression had kept. Anything that has never been forced to choose what to keep has only ever performed the first.

The same mechanism has a second face. Compressed judgment and settled prejudice are produced by the same process and feel identical from the inside, which is why “we tried that and it did not work” is simultaneously the most valuable and the most obstructive sentence available in a design discussion. There is no internal test that separates them, and anyone who believes they can tell the difference in their own case has supplied the evidence against themselves.

A Record of Survivors

Suppose you set out to capture the paragraph in the repository. Two things stand in the way, and they are independent of each other.

The first is that its content is counterfactual. It failed because the halves kept needing the same data and the team was reorganised away says that had those things not obtained, the split might have held. That is a claim about a world that did not happen. Records contain what happened. There is no amount of diligence in recording events that yields a claim about the ones that did not occur, because the claim is a judgment made in the light of subsequent events, and the judgment is the thing being sought.

The second is that the assets contain only survivors. Paint keeps its revisions. Under multispectral imaging the Mona Lisa still holds its transferred charcoal underdrawing, the repositioned hands, the adjusted horizon, dozens of thin glaze layers laid one over another.⁵ Overpainting covers without destroying, so the history remains in the object and can be recovered five centuries later. Code looks like it has an equivalent, and a better one. Version control keeps every state that was ever committed, and a deletion can be recovered years afterwards by anyone who knows where to look. The difference is in what gets preserved without anyone choosing to preserve it. Overpainting keeps the discarded attempt because covering something does not remove it. A repository keeps what somebody decided to record, and a dead end is the least likely thing to be recorded.

The revisions that carried the most reasoning were mostly never committed at all. The branch abandoned after two days. The approach tried for twenty minutes in the editor and reverted. The design considered over coffee and dismissed for a reason nobody thought to write down because at that moment it was obvious to everyone present. So the record is not merely incomplete. It is incomplete in exactly the dimension that carries the rationale, and it is systematically biased toward what worked, which is the part you can already see in the code.

Commit messages have their own version of this. They are thin on why, and not primarily through carelessness. At the moment of committing, the why is self-evident to the author, and nobody records what they currently find obvious. So the record is thinnest precisely where the writer’s understanding is thickest, which is the inverse of what a later reader needs.

Architectural decision records are the deliberate remedy and they invert the problem without dissolving it. An ADR captures the reasoning at the moment of deciding, which is before the decision has met anything. The paragraph is post-hoc, and the post-hoc part is the valuable part. By the time the outcome is known, the document has stopped being edited.

Told Only When Asked

Watch how this knowledge moves between people, because it does move, reliably, and the mechanism is not documentation.

Somebody new joins. They are given a small change. They start work, hit something that makes no sense, and ask why it is like this. Somebody who knows tells them, in about ninety seconds, and the answer sticks. Repeat for six months and they can modify the system safely. This is the normal path, it is how it has always worked, and it is worth saying plainly that this is a practitioner’s observation rather than a measured result; the research on onboarding tends to measure time to first commit, which is a different and easier thing than time to change something without breaking it.

Two things about that exchange matter. The knowledge transferred was not inexpressible. It went into words easily, in a sentence or two, and would have been perfectly clear written down. It was simply never told in advance, because nobody knew which of ten thousand possible things this particular person needed told until they tripped over one of them.

And the transfer was pull-based. The question was generated by an attempt, and the answer landed because it met a confusion the asker was already holding. The same sentence, delivered in week one as part of an onboarding pack, passes straight through. It has nothing to attach to.

Naur reaches the same conclusion about how a new programmer comes to hold what he calls the theory of an existing program: access to the program text and the documentation is insufficient, and what is required is working in close contact with people who already have it, doing the relevant things under guidance. That is a claim about the form of the transmission, not its volume.

An objection is due here, and it comes from Polanyi rather than against him. He is explicit that where the relations between the parts of something can be stated explicitly, they should be, and that explicit integration of this kind reaches further than tacit integration does. His example is a machine: the person who can operate it skilfully knows less about it than the engineer who understands its construction. So this is no argument for leaving things unwritten. Write down every relation that will go into words.

The answer is the compiler case. Those relations were written down, at length, and the new team still assembled a different shape and reasoned from it. Explicit statement is worth doing and it does not substitute, because what fails to transmit is not a set of statements.

Where the Documents Come From

Which brings the remedy into view, and its problem.

Every document that would let someone inherit the shape is written by someone who holds it. The architectural notes, the decision records, the account of what was considered and rejected and why, the paragraph itself if anyone ever writes it down: all of it is produced by people who came to know these things by having done the deciding. The documentation is a by-product of the activity. It is not an input to it.

So under an arrangement where the deciding is delegated, everything downstream fails together and for one reason: nobody accumulates the shape. Because nobody accumulates it, nobody writes the documents that would transmit it. Because nobody holds it, there is nobody to answer the question when the newcomer trips over something in week three. The documentation strategy does not fail because documentation is weak. It fails because its supply came from the activity that was removed.

This is where the current moment enters, and it enters as an application rather than a complaint. Coding agents have improved quickly along a particular axis. Context windows have grown. Models read existing code before changing it, and read it well. Retrieval and tool access make system state, past decisions and architectural notes available to them. These are real improvements and they are all improvements at consuming the record. None of them produces it.

Persistence is the interesting case, because it looks like the answer. An agent with long-term memory of a system is present across the interval, which is the thing a fresh session lacks. But presence is not what generates the paragraph. The paragraph comes from having committed to something, having been wrong, and having revised what was worth keeping. An observer who did not decide accumulates a record. That is the artefact problem again, at a different location. And if some future arrangement does produce an agent that has accumulated the residue over years, the shape now resides in something an organisation cannot question counterfactually, cannot promote, and cannot ask to explain itself to a newcomer at the moment of confusion. That is a relocation of the problem rather than a solution to it, and arguably a worse position than the one it replaced.

None of this rules anything out. It leaves two questions, which any arrangement for building software has to answer, and which are the same two whatever writes the code.

Does the process stay open to signals that only arrive later?

And is there anybody still present who can act on them and pass them on?

¹ Peter Naur, “Programming as Theory Building”, Microprocessing and Microprogramming 15, no. 5 (1985): 253–61. The case appears in his section on programmers’ knowledge, and the paper as a whole is the origin of the argument that a program’s theory is held by people rather than recorded in its texts.

² Michael Polanyi, The Tacit Dimension (New York: Doubleday, 1966; Anchor edition 1967), 10–13. Polanyi names the two ends of this relation the proximal and distal terms; the vocabulary is worth having if you go to the source, and the face does the work without it.

³ D. L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, Communications of the ACM 15, no. 12 (1972): 1053–58. Worth reading in full for its own account of what a good decomposition is, and for the moment where Parnas returns to his own worked example and finds a design error in it that only hindsight revealed.

⁴ See also “What Coding Was For”, which works on the same territory from a different angle: what the coding phase contains, rather than where the resulting knowledge ends up.

⁵ Successive imaging studies of the Louvre panel, including Pascal Cotte’s multispectral work, have recovered underdrawing and pentimenti beneath the finished surface.

The Shape Nobody Wrote Down was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

A second perspective sits alongside the first and seems to oppose it. Too little care for detail is itself what produces the flood. Definitions left vague get resolved downstream, repeatedly and inconsistently; the collisions become rework; the wrong thing built becomes waste; the absence of a settled aim becomes priorities that will not hold still. And that, in turn, is what leaves no room for strategy. On this telling, the product manager does not lack strategic time because of detail. They lack it because of a particular failure of detail.

Both are commonly true, and set side by side they look like a contradiction to be resolved by finding the right amount of detail, not too much and not too little. That resolution explains nothing. “The right amount” is a free parameter that absorbs whatever answer was wanted in advance. The two claims are not competing over a quantity. They are not talking about the same detail at all. One word is carrying two kinds of work, and the gap between them is where the whole problem lives.

A word with a cut in it

The word “detail” comes into English through French, from an old word for a piece cut off: a slice, a portion taken from something larger. Behind it sits the verb to cut. The same root runs into another English word that kept better company with its origin: tailor. A tailor cuts, but cuts to fit; the pieces are sized so that they assemble into something that holds together on a particular body, for a particular purpose. The two words are siblings. They inherited the same act of cutting and went different ways with it.¹

Detail went the way of decay. Somewhere in its descent it acquired the sense it now wears most often: a small and subordinate part, a minor element, the kind of thing one leaves to others. That sense is a late coat of paint. There is no smallness and no subordination in the root. A cut is just a cut; what it produces can be the sleeve or the offcut, the load-bearing piece or the scrap on the floor. The word lost the tailor’s half, the cut-to-fit, the piece sized to a purpose, and kept only the diminutive.

This matters here for one reason. The collapse we are about to examine, the one that lets two kinds of work hide under a single name, is not a careless modern slip that a sharper writer could correct. It is built into the word as it was handed down. The language itself stopped distinguishing the cut that fits from the scrap that falls. We inherited the confusion. No one chose it.

Two kinds of detail

Set the tailor aside and look at what the word carries.

Start with the fact that “detailed” is heard as one thing when it is two. When we call work detailed, we can mean that it sits low down, close to the small and operational, far from the heights where direction is set. Or we can mean that it is fine-grained: that it holds many small particulars at once and relates them to each other. These are different measures. One is altitude, how high or low in scope the work sits. The other is grain, how fine the resolution of attention is. The word fuses them, and once fused, “detailed” is heard as “low”, because the decayed sense of the word supplies the default.

Altitude and grain are not the same measure, and the proof is that they vary independently. You can work at low altitude with fine grain: careful operational craft, the small thing done exactly. You can work at low altitude with coarse grain: going through the motions. And you can work at high altitude with fine grain, which is the case the fused word makes almost impossible to see. That is strategy done as detailed work: holding many fine particulars about users, constraints, sequence and consequence, and relating them so that a direction emerges which will hold when it meets contact. Strategy of that kind is not the opposite of detail. It is detail, carried at altitude. The settling of an aim is made of particulars, or it is made of nothing.

It is worth stopping to ask whether this second kind is a real category or a flattering name I have put on ordinary diligence. The test is whether it does distinct work, and whether its absence has distinct consequences. It passes. The definitional decisions it consists of, what counts as done, which user is being served, which trade-off is being accepted, get made somewhere by someone, whether deliberately at altitude or by accident at the point of contact. If they are not made high with grain, they are made low without it, by whoever meets the ambiguity first. So the category is not a compliment I have invented. It is a location where certain decisions can be taken, and the only question is whether they are taken there or displaced.

Give the two kinds their working names. Operational detail is near the work and easy to see: the ticket that needs a decision, the dependency that needs chasing, the question from engineering that needs an answer now. It is detail in the decayed sense, small and immediate, and it arrives in volume. Definitional detail is the high-altitude, fine-grained work: settling what is being built, for whom, against what aim, with which edges decided in advance. It is strategic and granular at the same time, and those are not in tension.

Here is the property that governs everything that follows. The second kind is close to invisible, and its invisibility has a structure worth setting out, because the structure is what leaves it defenceless.

It cannot be measured, because what it produces is the non-occurrence of trouble. You can count the fires that break out; you cannot count the fires that never started. A team that never has the integration collision has nothing to hold up.

It cannot be attributed, because when things go smoothly the smoothness is credited to whatever is visible: the delivery, the engineers, the quarter that happened to be calm. The upstream decision that made the calm possible leaves no fingerprint on it.

And it cannot be defended by counterfactual, because no one can prove the flood would have come. The claim “this work prevented a mess” is unfalsifiable from outside, and so it sounds like special pleading exactly when it is true.

Three ways of leaving no trace, and together they mean the work is too granular to read as strategy in the room and too abstract to read as urgent on the board. It is squeezed from both sides, and it registers as nothing anyone is equipped to notice.

The remedy that cannot tell them apart

Put the two kinds together with the standard fix and watch what happens.

The complaint arrives first: the product manager is too focused on detail, and has no time for strategy. It is meant in good faith and is often correct as an observation. But notice what it can possibly be pointing at. It can only point at the visible kind. The invisible kind cannot be complained about, because it cannot be seen well enough to register as a quantity of anything. So before any reasoning begins, the diagnosis is already aimed at operational detail. It could not have been aimed anywhere else.

The remedy follows from the diagnosis: reduce the detail. Free the product manager from the operational load. Clear the inbox, delegate the tickets, build a buffer, and let them rise to the strategic work.

Here is the misfire. “Reduce detail” is an instruction addressed to a word, and the word names both kinds of work. Subtraction cannot reach only the visible kind; it has no handle for the distinction, because the distinction was lost in the language. When the load comes off, it comes off both. The operational detail recedes, and so does the time, the standing and the permission for the definitional detail, which looked like just more detail to be cleared. The fix removes the very work that was holding the downstream chaos shut.

Follow what reopens, because the reopening is not one thing but three, running on three different mechanisms that the argument has so far let blur.

The first is rework. A definitional decision left unmade upstream does not vanish; it waits at the point where the work meets it, and there it is made locally, by whoever arrives first, in the way that suits their corner. A second person, at a second corner, makes it differently. The two local resolutions were never reconciled, because there was nothing to reconcile them against, and when the pieces come together the mismatch surfaces as rework. Rework is the cost of a decision taken many times instead of once.

The second is waste, and it is not the same thing. Rework is building something twice. Waste is building the wrong thing once. When the aim was never settled, effort flows toward a target no one confirmed, and the finished, correct, well-built result turns out to be beside the point. Nothing was done twice. It was the wrong thing, done well.

The third is priority churn. Without a settled aim there is no stable basis for ranking, so the ranking follows whatever pressed most recently: the loudest stakeholder, the latest incident, the meeting that just ended. Priorities that will not hold still are not a lapse of discipline in the ranking; they are the absence of the thing ranking requires, which is a fixed point to rank against.

Three costs, three mechanisms, one cause. The definitional work that would have fixed the point, done the reconciling and settled the aim was cleared away with the operational load, because both wore the word “detail” and the remedy had no handle for the difference.

And all three surface the same way. Rework, waste and churn are only ever visible as operational detail: more tickets, more clarifications, more of the small thing that will not wait. The product manager is buried again. The complaint is accurate again: too focused on detail. The remedy is prescribed again. The wheel turns, and each turn of it is the cure.

This is the essay’s real claim, stated plainly so it can be argued with. The remedy does not merely fail. It feeds the condition it was prescribed to treat, because it starves the one kind of detail that prevents that condition, and it starves that kind precisely because the kind cannot be seen and so cannot be spared.

But sometimes the complaint is right

That claim is now strong enough to be worth attacking, and the strongest attacks come from conceding what it has quietly assumed.

Assume first that all cleared detail was load-bearing. It was not. A great deal of operational detail is noise: status rituals that reassure without informing, reports no one reads, meetings held to be seen holding them, decisions a product manager keeps hold of out of anxiety or distrust rather than need. Clearing that costs nothing and helps at once. Some product managers are over-involved in the plain sense; they hold detail they should hand off, and the complaint about them is simply accurate. The displacement view is not a fantasy. It describes a real person.

Assume next that the flood is self-generated. Often it is not. Markets move, executives change their minds, reorganisations arrive, a competitor ships and the roadmap is overturned from outside. Churn of that kind owes nothing to any upstream definitional gap, and against it the shielding remedy is exactly right: protect the product manager from exogenous noise so the strategic work can proceed. Not every buried product manager was buried by their own skipped decisions.

Now the sharpest concession, because it turns the essay’s instrument against the essay’s favourite. Definitional detail is not virtuous by nature. High-altitude, fine-grained work can be a hiding place as readily as low work can. There is a failure mode that looks identical to diligence from the inside: endless discovery, endless refinement, the aim re-settled once more rather than committed to, all of it defensible as getting the definition right and all of it a way to postpone the exposure of shipping. Over-investment in the invisible work is real, and it is harder to catch than the operational kind for the same three reasons the good version is hard to see. It cannot be measured, attributed or falsified either. The properties that protect load-bearing definitional work from being seen also protect definitional avoidance from being caught. The shield covers the diligent and the hiding alike.

So the honest position is not that clearing detail is wrong, nor that definitional work is always the answer. Sometimes the complaint is right, the detail is excess, and the person should let it go. Sometimes the definitional work is avoidance wearing the costume of rigour. Both happen, and admitting them looks at first as though it dismantles the argument.

It does the opposite. Notice what every one of these concessions has in common. In each case the thing required is a judgement: is this detail load-bearing or noise, is this flood endogenous or external, is this definitional work the real thing or a place to hide. And in each case the remedy has no instrument for making it. “Reduce detail” cannot tell excess from load-bearing, and it cannot tell rigour from avoidance either, because the word it operates on has collapsed all of these into one undifferentiated mass. The steelman does not rescue the remedy. It widens the charge. The trouble was never that the invisible work is always good and should always be spared. The trouble is that the collapse of the word disables judgement in every direction at once, so the remedy cannot spare what deserves sparing, cannot cut what deserves cutting, and cannot tell which is which.

When the remedy works, and why it usually does not

This gives the precondition its proper shape. The remedy is not harmful in itself; it is harmful under a condition, and the condition is now visible. The backfire requires that the load be subtracted without any judgement taking the place of the word it was addressed to. Pair the subtraction with discrimination, a way to tell load-bearing definitional work from excess and to tell it apart from its avoidant twin, together with redirection of the freed attention toward the work discrimination marks as load-bearing, and protection of that work once it is under way, and the remedy does what it promised. The operational load comes off, the freed attention goes to settling aims and edges, and the downstream gaps close rather than reopen.

State the honest version, which is narrower than the claim it corrects. The default form of the remedy backfires. The safe form is rare. And the reason the safe form is rare is the property that started all this. You cannot discriminate work you cannot see, you cannot redirect toward it, and you cannot protect it. All three require that the definitional detail be legible as a thing worth telling apart, and its defining feature is that it is not. The visibility asymmetry that biased the diagnosis also disables the cure. It makes subtraction-without-judgement the path of least resistance, because judgement asks you to weigh something that shows no trace.

What is left when the grain comes out

There is a particular residue worth naming, because it is routinely mistaken for success, and the altitude-and-grain distinction names it exactly.

When the operational detail is stripped and the definitional detail is stripped with it, the product manager is left at altitude with nothing fine-grained left to hold. In the terms from earlier, they have been moved into the one remaining corner: high altitude, coarse grain. That corner has a familiar look. It is strategy in outline only: the deck, the north star, the roadmap with no settled edges beneath it. It reads, in the room, as exactly the strategic elevation everyone was reaching for. The product manager is no longer buried. They are speaking in the register of direction.

But the durability that strategy needs was made of the grain that was just cleared away. A direction that has not been cut to fit any actual case does not hold against contact; it is a shape with no seams. The freed product manager produces something that looks more strategic and is less so, and the gap will not show until the undefined edges are met downstream and the rework begins, at which point it returns, as always, as operational detail. The remedy reaches for strategy and delivers its costume.

One person, two complaints

The two perspectives we began with were never in conflict. The first watched the product manager drown in visible detail and concluded there was too much of it. The second watched the same person and concluded the trouble was too little of a different detail, upstream and out of sight. They were describing one person from two angles, and the word that should have separated the angles instead fused them, as it has done since it lost its tailor’s half.

I have drawn the loop as though it turns on its own, and it is worth saying where that is too clean. The wheel is not a mechanism that runs without people. It runs because at each turn the visible reading is the available one and the invisible reading is not, and people reach for the reading they can act on. Break the visibility asymmetry at any point, give the definitional work a trace, a name, a place where its absence can be seen before the flood arrives, and the loop loses its necessity. What has been described is a strong tendency, not a law. What makes the tendency strong is not that people are foolish. It is that the language hands them one reading and hides the other.

Which is why what follows is not a prescription, and a prescription would betray the analysis. The moment you say “protect the definitional work” you are asking people to see and value the thing whose nature is to leave no trace, and to tell it apart from the avoidance that shares its face. The difficulty is not that the answer is hard to carry out. It is that the answer is hard to see as an answer at all. The detail that prevents the detail does its work by not happening, and a thing that succeeds by leaving nothing behind is a thing we are very poorly equipped to defend, or to question.

¹ “Detail” and “tailor” descend from the same root. “Detail” comes through French from a word for a piece cut off, from taillier, to cut; “tailor” runs through that same verb of cutting back to Latin talea, a cutting or slip of wood. The “small and subordinate part” sense of “detail” is a later development, not present in the root. Merriam-Webster word histories: detail and tailor.

The Detail That Prevents the Detail was originally published in Classroom on Medium, where people are continuing the conversation by highlighting and responding to this story.