← The Method
The Method · 05

Publish

Stage five of The Method. Only what endures.

It is easier than ever to ship. The button is often right there: a push, a merge, a deploy, and your code is in the world. Publishing is something else, and the distinction is the whole of this stage. To publish is to make a judgment: that this, of all the things you could release, is worth carrying forward — into the maintenance burden of years, into the minds of people who will read it long after you’ve forgotten writing it, into the slow layers of a system where things are supposed to last.

The Elemental Codices publish “only what endures,” and the phrase contains a deliberate severity. Many ideas should never reach this stage. They are observed, conjectured, formalised, and then — refuted, or simply found wanting — allowed to die. That mortality is not the method failing. It is one of the method’s outputs. The restraint is part of the product. What survives to publication should survive because the four prior stages were honest enough to filter out what should not yet be carried forward.

You write code once and read it for years

Start with the asymmetry that makes publication consequential. Robert Glass, in Facts and Fallacies of Software Engineering, reports that maintenance typically consumes 40 to 80 percent of total software lifecycle cost — making it, by his reckoning, the most important phase of the life cycle — and that roughly 60% of that maintenance is enhancement, not defect correction.1 You do not write a system and walk away. You, or someone who inherits your theory, lives inside it for years, mostly adding to it.

This reframes what publication is. The moment you publish, the code stops being your private draft and becomes a text other people must read, extend, and trust — the artifact from which they will try to reconstruct, in Naur’s sense, the theory you held. A large share of its cost, and often much of its useful life, lies after the moment of release. Which means the question at this stage is not only “does it work?” — Demonstrate should have answered that well enough to continue — but “will the next person be able to live with this?” Publishing is an act of consideration for readers you will never meet, and the discipline of it is writing for them rather than only for the compiler or the deadline.

”Endures” does not mean frozen

A naive reading of “only what endures” imagines publication as carving something permanent in stone. The opposite is true, and Manny Lehman’s work explains why. His laws of software evolution begin with the Law of Continuing Change: an E-type program — one embedded in real-world activity — must continually change, or it becomes progressively less satisfactory as the world it models keeps moving.2 His second law, Increasing Complexity, supplies the catch: as such a program evolves, its complexity tends to grow and its structure tends to deteriorate unless work is explicitly spent to hold that decay back.2

Put the two laws together and “endures” acquires its real meaning. To endure is not to stay still — staying still is one way software dies, by growing slowly useless. To endure is to remain changeable: to be structured so that continuing change can be absorbed without complexity growth crushing it. What endures is not the frozen artifact but the living, legible, modifiable core. You are not publishing a monument. You are publishing something that may have to survive being edited by people who were not present when it was made, and the bar for that can be higher than the bar for a monument, not lower.

Choose your debt, and write down the loan

Often you publish knowing it is not perfect. There is a deadline, an understanding still forming, a corner deliberately cut. This is not automatically a sin — but whether it is depends on a distinction the industry has spent thirty years getting wrong, so return to the source.

Ward Cunningham coined the technical-debt metaphor in a 1992 experience report, and his actual words are more careful than the slogan they became: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”3 Years later, watching the metaphor get abused, Cunningham clarified what he had meant: the debt is shipping code that reflects your current, best, but still partial understanding — in order to get it in front of reality and learn faster — and then repaying it by refactoring as your understanding improves. It was never a license to write sloppy code and call the mess “debt.”3

That distinction is the discipline of intentional publication. Debt taken deliberately, in full view, with a visible repayment plan, can be a legitimate instrument — sometimes the right instrument, because shipping to learn beats polishing in ignorance. Debt taken by negligence and never acknowledged is just rot with a respectable name. To publish intentionally is to know which corners you cut, to write the loan down where the next reader can see it, and to mean the repayment. The TODO that names the shortcut and the ticket that schedules the fix are not bureaucracy; they are the difference between a deliberate loan and a silent default.

Code is literature, addressed to people

If much of a system’s useful life is spent being read, then the published artifact’s highest obligation is to be legible — and the most uncompromising statement of that obligation is Donald Knuth’s. In “Literate Programming” (1984), he inverted the usual priority: “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.”4 A program, in Knuth’s view, should be a work of literature — composed for a human reader, with machine-readable code generated from the same deliberately ordered explanation.

Knuth lived the standard to a degree that has become legend, and the legend is worth telling because it is the most extreme emblem of “only what endures.” He has offered reward checks for genuine bugs found in TeX — recipients have famously framed the checks rather than cashing them — and TeX’s version number does not climb toward 4.0. Since version 3 it has gained digits of π with bug-fix releases, converging on π, with Knuth’s stated wish that TeX be frozen at version π after his death and that no further changes be made to his source.5 That is not a general release strategy for ordinary software; it is an extreme benchmark of stability. The ideal this stage points toward is not software that merely gets released, but software whose change surface has been intentionally narrowed because there is less and less left to take away.

Few of us will publish a TeX. The standard still orients us. Publish for the reader. The clarity you spend now is repaid again and again across the large share of lifecycle work in which someone is trying to understand and change what you wrote.

Separate the essence from the accident

What, concretely, is the thing worth enduring? Fred Brooks gave the sharpest answer in “No Silver Bullet” (1986). He divided software’s difficulties into the essential — the irreducible complexity of the conceptual construct itself, the genuine intricacy of the problem — and the accidental — the difficulties that attend our tools and methods but are not inherent to the problem.6 His pessimistic, durable thesis: decades of progress can make large gains against accidental complexity, but no single advance promises an order-of-magnitude gain against essential complexity, because that complexity is bound up with the problem itself.

Publication is the act of separating the two and committing to the right one. The accidental scaffolding — the framework of the moment, the boilerplate, the cleverness that impressed you on Tuesday — is what rots fastest and matters least. The essential core — the clear conceptual model of the problem, the few good ideas applied with integrity — is what deserves to endure and what the next maintainer actually needs. To publish well is to make the essence prominent and legible, and to keep the accidental from accreting over it until, as Lehman warned, the structure deteriorates past saving. You are curating, not just committing.

The honest counterpoint: “worse” often wins

A method that preached only endurance, polish, and restraint would be lying about how software actually succeeds, so confront the strongest objection directly. Richard Gabriel made it in “The Rise of Worse Is Better.”7 He contrasted two design philosophies: “the right thing” — the MIT approach prizing correctness, completeness, and consistency even at the cost of simplicity — and “worse is better,” the New Jersey approach that prizes simplicity of implementation above all, even when it sacrifices some correctness and completeness. His unsettling observation was that the “worse,” simpler, ship-it-now systems frequently win — they spread faster, get adopted more widely, and survive, while the more correct “right thing” arrives late and loses.

Take this seriously, because it appears to refute the whole stage. If worse wins, why publish only what endures? The resolution is not to dismiss Gabriel but to read him precisely. The systems his “worse is better” describes did not endure despite being unfinished; they endured because their core was simple enough to carry forward, adapt, and build upon. That is Hickey’s simplicity from the Conjecture essay, reappearing as a survival trait. “Only what endures” is therefore not a mandate for gold-plating — gold-plating is accidental complexity, exactly the thing Brooks says rots, and the perfectionism Gabriel warns against. What endures is the simple, legible, sufficient core shipped early enough to matter and clean enough to grow. Endurance and restraint-in-shipping are not opposites; both are enemies of the over-built. The thing to publish is the smallest core that does the job and can be carried forward — not the most complete one.

Know which layer you are building for

The widest frame on this stage comes from outside software entirely. Stewart Brand’s concept of pace layering describes how durable complex systems are organized into layers moving at different speeds: in civilization, from fast to slow, fashion, commerce, infrastructure, governance, culture, and nature. Long Now summarizes the diagram’s caption this way: “The fast layers innovate; the slow layers stabilize. The whole combines learning with continuity.”8 The health of the whole depends on the layers being different speeds and respecting one another — the fast layer free to experiment because the slow layer holds steady beneath it.

Software can be read through the same lens. There is a fast layer — features, experiments, the UI of the season — where shipping quickly and discarding freely may be correct, and where a heavy “only what endures” bar would be a category error. And there is a slow layer — the core data model, the public API, the protocol, the infrastructure everything else stands on — where change is expensive and endurance matters because the rest of the system has come to depend on relative stability. The discipline of this stage is to know, every time you publish, which layer you are writing into. The bar for the slow layer is severe, and rightly so: a published API is often a promise measured in years. The bar for the fast layer is lower, and pretending otherwise just slows you down where speed is cheap. Publishing well is matching your restraint to the layer — heavy where things must last, light where they’re meant to be replaced.

The discipline of fewer things

The method’s spirit, finally, is named most directly outside our field, by Cal Newport. His Slow Productivity (2024) reduces to three principles: do fewer things, work at a natural pace, obsess over quality.9 All three are this stage in miniature. Do fewer things: publish less, so that what you publish can be done to a standard that lasts. Work at a natural pace: cycles, not sprints. Obsess over quality: the thing that endures is the thing made well enough to deserve to.

This is the answer to anyone who hears “slow, intentional coding” as an excuse for slowness. It was never about being slow. It is about spending your finite attention on fewer things, carried further. Over the years measured by Lehman and Glass, a team that publishes fewer durable things is more likely to outlast and outlearn a team that ships many things it is then forced to maintain, especially when much of that inventory was never worth carrying forward. Restraint is not the cost of the method. Restraint is the leverage.

The honest limit: “only what endures” can become an excuse never to ship

The failure mode of this stage is the most seductive in the whole method, and the Codices are not immune to it, so name it plainly. “Only what endures” can curdle into perfectionism — the polish that never ends, the bar so high nothing clears it, the quiet vanity of refusing to release anything imperfect. Gabriel’s warning cuts here too: the “right thing,” pursued past the point of usefulness, loses to the merely good thing that actually shipped. A codex that publishes nothing is not pure. It is silent, and silence teaches no one.

The corrective is the whole cycle, which is why this stage is the last and not the only one. The bar for endurance is not met at publication by heroic last-minute polishing. It is met upstream — by observation honest enough to understand the problem, conjecture bold enough to find a simple shape, formalisation precise enough to be checkable, demonstration rigorous enough to trust. By the time an idea reaches Publish, most of the work that makes it durable should already be done; this stage judges whether that work is sufficient. So many ideas are filtered out early, on purpose, cheaply — not strangled at the end by a perfectionist gate. What reaches publication is meant to be both finished and worth finishing, and the way you get there is not by polishing forever but by killing the unworthy ideas while they’re still cheap to kill. Ship the durable thing. Let the rest die young.

What Publish looks like in practice

The handoff — and the loop closes

Publish looks like an ending. It is not. The Method is a cycle, not a ladder, and its final stage feeds its first. What you publish becomes part of the world that the next Observe must gather as what is — your API is now the territory someone else reads before they conjecture, your schema the constraint they formalise against, your published system the running thing they observe. The loop closes. “Cycles, not sprints” is not a slogan about pace; it is the literal shape of the method. Stage five flows back into stage one, on this system or the next.

This is where slow, intentional coding reveals what it was always about. Not slowness — some verification can run in seconds, and high-performing teams can ship frequently. It is about where you spend your care: early, on understanding, where mistakes are cheap; and at the end, on selection, where you decide what is worth the long cost of enduring. Software’s expensive mistakes are often made early and paid for late. The Method front-loads the thinking so some of that downstream payment is avoided, and back-loads the judgment so that only what deserves to last is allowed to. We build slow by design. We publish only what endures. And then — having gathered, proposed, formalised, demonstrated, and at last chosen — we begin again.

Footnotes

  1. Robert L. Glass, Facts and Fallacies of Software Engineering (Addison-Wesley, 2003). A web-resolvable listing of the book’s facts gives Fact 41 as “Maintenance typically consumes 40–80% of software costs” and Fact 42 as “Enhancements represent roughly 60% of maintenance costs”: Eyrolles. ↩

  2. Meir M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution,” Proceedings of the IEEE 68, no. 9 (1980): 1060–1076. DOI: 10.1109/PROC.1980.11805. The cited laws apply to E-type programs, i.e. programs embedded in real-world activity. ↩ ↩2

  3. Ward Cunningham, “The WyCash Portfolio Management System,” Addendum to the Proceedings of OOPSLA ‘92. DOI: 10.1145/157709.157715. Full text: c2.com/doc/oopsla92.html. Cunningham’s later clarification that the metaphor was never an excuse for sloppy code is summarized at c2.com/cgi/wiki?WardExplainsDebtMetaphor. ↩ ↩2

  4. Donald E. Knuth, “Literate Programming,” The Computer Journal 27, no. 2 (1984): 97–111. DOI: 10.1093/comjnl/27.2.97. Reprinted in Knuth, Literate Programming (CSLI, 1992). The “explaining to human beings” and “works of literature” framing is from the paper’s opening. ↩

  5. For TeX’s future maintenance and version number tending toward π, see The TeX FAQ. For a contemporary archived message about Knuth reward checks for TeX 3.14159 bug reports, see TeX 3.14159 — Rewards for finders of bugs. ↩

  6. Frederick P. Brooks, Jr., “No Silver Bullet — Essence and Accident in Software Engineering,” in Information Processing 86 (IFIP, 1986), 1069–1076; reprinted in Computer 20, no. 4 (April 1987): 10–19. DOI: 10.1109/MC.1987.1663532. ↩

  7. Richard P. Gabriel, “The Rise of Worse Is Better” (written ~1989; widely circulated from 1991), originally part of “Lisp: Good News, Bad News, How to Win Big.” dreamsongs.com/RiseOfWorseIsBetter.html. Gabriel himself remained ambivalent and later argued both sides. ↩

  8. Stewart Brand, The Clock of the Long Now: Time and Responsibility (Basic Books, 1999). Long Now’s pace-layer summary gives the origin, six layers, and the caption “The fast layers innovate; the slow layers stabilize”: Long Now. ↩

  9. Cal Newport, Slow Productivity: The Lost Art of Accomplishment Without Burnout (Portfolio/Penguin, 2024). Newport states the three principles as do fewer things, work at a natural pace, and obsess over quality on his book announcement page: Cal Newport. ↩

  10. Daniele Procida, Diátaxis documentation framework: diataxis.fr. Four modes — tutorials, how-to guides, reference, explanation — organized along action/cognition and study/work axes. ↩