Overview
Before architecture, implementation, and deployment comes a question that can ruin an otherwise excellent planning meeting: does this artifact need to exist at all? Everybody has already agreed on the repository name. It feels unkind to bring reality into it now.
An Apple Is a Ridiculous Amount of Work
An apple is a deceptively small achievement. You walk into the kitchen, pick one up, wash it if you are feeling responsible, and eat the outer two-thirds. Perhaps you navigate around a bruise. Perhaps you leave a heroic centimetre of perfectly good apple attached to the core because getting closer would require an awkward rotation and a level of commitment you did not bring to lunch. Then you throw the rest away, having successfully consumed the part for which you believe the entire arrangement exists.
To produce those six bites, the world first had to grow a tree. Not an apple dispenser with a convenient trunk attached, but roots, bark, branches, leaves, blossoms, and a reproductive strategy involving third parties with wings. The tree requires water, soil, microbes, suitable weather, and years of sunlight. The pollinators require other plants and somewhere to live. Somewhere downstream are farmers, refrigeration, trucks, grocery stores, and a teenager putting the Honeycrisps in the wrong bin again. The apple costs three dollars because nobody has itemized the universe.
Then your body extracts a relatively small amount of useful energy and material through a digestive system you have been operating your entire life without once scheduling a dependency upgrade. The energy eventually becomes motion, thought, bodily maintenance, and heat. It does not remain in an internal apple battery. Eating one at age seven does not settle the matter through retirement, although a subscription service would certainly advertise the possibility.
At first glance, this looks like staggering waste. We grew an orchard, involved the bees, transported the fruit, and maintained an entire organism so that I could stand over the kitchen sink and decide the remaining bit was too difficult. But the accounting is suspiciously centered on me, which is often where suspicious accounting begins.
The seeds are not manufacturing defects. From the tree's perspective, they may be the principal deliverable, while the flesh is a marketing expense incurred to persuade an animal to distribute them. The leaves are not unnecessary because I decline to eat them. The roots are not overhead that an ambitious tree startup can eliminate in version two. What looks disposable from one position may be essential from another; the tree has not agreed that my snack is its corporate mission.
The apple is the visible result at the tip of an enormous dependency cone. This does not establish that apples are a mistake. It establishes that looking at the fruit is a poor way to estimate what makes fruit possible, which brings us, regrettably, to software.
Every Tool Requires a World
A small software tool looks cheap. One repository, six source files, a build configuration, and a README containing an example that worked on the author's laptop on the afternoon it was written. The implementation took two days. Someone posts a rocket emoji, whose exhaust does not appear in the estimate.
Unfortunately, source code is only the trunk. The tool needs tests, releases, packages, documentation, compatibility decisions, and somebody who remembers why it behaves differently on Tuesdays. Depending on what it does, it may also need authentication, authorization, networking, monitoring, deployment automation, and a Kubernetes cluster. We began with a command that rearranges a string and have arrived at a staffing question.
Users learn it. Applications integrate it. Pipelines call it. Other systems generate its inputs and interpret its peculiar outputs. People write wrappers because the interface is almost right, then wrappers around those wrappers because the first wrappers belong to another department and changing them requires a meeting. The repository remains admirably small. The meetings have not been committed to it.
A tree offers an inconvenient illustration of how this happens. If a large tree weighs tonnes and grows out of the ground, why is there not a tree-sized hole underneath it? Where did the material come from? I admit this question troubled me longer than it should have. The ground appeared to have supplied a tree while remaining entirely ground, which would be an impressive procurement arrangement.
Most of a tree's dry mass is built from material acquired through the air, especially carbon from carbon dioxide, rather than bulk soil hauled upward through the roots. The tree gains substance from something surrounding it that we usually do not notice. Water makes up much of its living weight as well; the point is not that soil contributes nothing, but that looking for a missing tree in the dirt misunderstands the transaction.
Tools acquire mass from their surroundings too. A flag becomes part of a deployment procedure. An output column enters a finance report. A bug becomes something every consumer compensates for, after which correcting it is called a breaking change. Somebody learns that retries must occur exactly three seconds apart and teaches the next person, without either of them finding this requirement in the code. The implementation is visible and countable. The dependency on it has become atmospheric.
Creation starts at the center and moves outward, one enthusiastic adopter at a time. Removal starts at the edges, except nobody knows where the edges are. You think you are deleting a program. Six months later, a report fails because a cron job still calls version 1.3 from a server everyone believed had been decommissioned in 2019. The server is named temp-final-2, which is not a name so much as a record of negotiations lost.
The useful accounting therefore includes creation, integration, operation, adaptation, and eventual extraction. These are categories, not independent quantities in a reassuring equation: changing the interface can increase integration cost, refusing to change it can increase operating cost, and making either choice without knowing the consumers can increase everyone's blood pressure. The original implementation estimate describes the part whose author was present to estimate it.
Creation is paid by the team making the decision. Integration is paid by adopters. Operations are paid by whoever gets paged. Extraction is paid years later by people who were not in the meeting and would like to know why a temporary command now participates in financial reporting. The ticket has been archived, the documentation returns 404, and the original team has achieved the only reliable form of decoupling: employment elsewhere.
Construction Has Excellent Visibility
Most engineering advice begins after the decision to create has already been made. Here is how to build a service, select a framework, structure a repository, and make the result observable, secure, reusable, extensible, and deployable across seventeen regions. We receive extensive guidance on maintaining the thing and remarkably little pressure to establish why there should be a thing to maintain.
Even advice against complexity tends to accept construction as the default. “Keep it simple” means build a simpler artifact. “You aren't gonna need it” removes optional features from the artifact we have already authorized. “Do not repeat yourself” sometimes replaces three repeated lines with forty-seven lines of abstraction, making the repetition disappear into a place where nobody can comfortably inspect it. “Reuse before build” may import someone else's dependency cone, release schedule, design assumptions, and newly creative interpretation of licensing.
None of these principles is useless, and several can reject the whole proposed artifact when taken seriously. We have a remarkable talent for applying them only after approving the repository. Under that interpretation, you can follow all of them faithfully and produce an exemplary system whose main accomplishment is giving six people something else to remember.
Artifacts are easy to recognize as work. We can count commits, pull requests, repositories, services, and launches. When morale deteriorates sufficiently, we can count lines. A requirement eliminated by one awkward question leaves much less evidence. There is no service to demo, no migration to announce, and no incident dashboard showing the failure mode that never existed. The engineer who prevented the project appears to have spent the week talking.
This is how construction passes for engineering: it leaves something we can point at. Restraint leaves a smaller invoice, a quieter pager, and an empty space in the architecture diagram that somebody will eventually propose filling. The savings are distributed. The absence of a launch is immediately visible to the person assembling the quarterly presentation.
The distinction also matters to the Neo-Fermi/Wilson AI paradox. If implementation output is abundant, we still need to ask where that abundance becomes a worthwhile outcome. More software is evidence that software was produced. Whether it improved the situation remains a separate investigation, usually scheduled after the celebration.
The Question Before the Ticket
The ordinary sequence is to build something that works, improve it, make it efficient, and remove whatever turns out to be unnecessary if there is still time. There is never still time. By then, applications depend on it, dashboards measure it, and somebody has colored it “strategic” in the roadmap. The unnecessary part now has stakeholders, which is how a technical fact acquires legal representation.
The sequence needs to begin earlier. Prevent an unnecessary obligation before taking it on; examine obsolete obligations before preserving them; build what survives the inquiry and make it work correctly. That may be a demonstrated necessity or a bounded experiment whose potential benefit warrants its cost, not merely another object approved because nobody could prove it useless. This is an order of inquiry, not an instruction to perform speculative deletions while everyone waits for a payment to settle. An existing component may need to remain during migration, and a necessary new one may need to arrive before the old one can leave. Reality is annoyingly unwilling to execute a manifesto in numbered order.
The Zeroth Law of Engineering is therefore: do not build what need not exist.
It comes before architecture, implementation, testing, and deployment because those activities cannot retroactively justify their own subject. A perfectly functioning unnecessary system may be harder to remove than a broken one. People will trust it, adopt it, and eventually describe its continued existence as a requirement.
A request usually arrives as a proposed object. “We need a dashboard” sounds settled until you discover that someone needs to know whether a process completed. “We need a database” may mean two executions must share one small piece of state. “We need a microservice” may mean nobody wants responsibility for a function already in the application. The named artifact conceals the actual constraint while giving the meeting something to estimate.
Swimming upstream means asking what happened, what outcome is required, and what prevents the existing arrangement from producing it. Sometimes the capability already exists. Sometimes a rule can change. Sometimes the report nobody reads can stop being produced, taking its proposed dashboard with it. Occasionally you still need the database, and now you have the rare pleasure of knowing what it is for before selecting one.
This is not a request to optimize a needless process until it becomes too impressive to cancel. In the fan-noise essay, reducing work and questioning its continuation are different moves. An engineer can spend six weeks making a job cheaper while carefully avoiding the person who could confirm that its final consumer stopped using it last February. The job becomes efficient. February remains unconsulted.
The Bamboo Has Not Read the Label
I own a PVC pipe cutter that I use to cut thick bamboo in my backyard. I do not believe I have ever cut PVC with it. The cutter seems untroubled by this departure from its stated career path, which is more than can be said for many people who discover their degree is not a physical law.
“PVC pipe cutter” is a market category. The relevant mechanism is a ratcheted shearing action suited to certain cylindrical materials. Bamboo can fit that mechanical contract without fitting the label. Searching for a bamboo-specific artifact would have been understandable and might have produced a very attractive purchase, but the bamboo would not have been cut any more convincingly.
The famous Knuth–McIlroy word-frequency example makes a similar distinction. Knuth wrote a substantial program as a demonstration of literate programming. McIlroy showed how existing Unix commands could compose the required transformations: split text into words, normalize, sort, count, rank, and select. One approach demonstrated how a program could be constructed and explained; the other demonstrated how the task could be expressed using capabilities already present.
They were serving different purposes. A teaching artifact does not become unnecessary merely because there is a shorter way to produce its output. If the requirement is to demonstrate literate programming, the program is doing work the pipeline is not. If the requirement is to count words, however, the pipeline deserves examination before we commission another executable and someone inherits its release process.
The useful alternative to bespoke software is not automatically one enormous tool with nine hundred flags. Nor is it a sixty-stage shell pipeline relying on accidental whitespace, locale-sensitive sorting, and a regular expression whose author disappeared from a forum in 2008. That is a custom program written sideways, with its dependency declarations distributed across your hopes.
What matters is whether the essential transformations already exist behind contracts stable enough for the job. Composition still needs validation, ownership, and an explanation of what happens when a stage fails. The absence of a new repository does not mean the absence of a new obligation. A pipe cutter can cut bamboo; it cannot make judgment unnecessary.
Let's Cook, Claude
A missing comma can move Claude from the person being addressed to the object of the sentence, which is a troubling start to a production specification. I mean “Let's cook, Claude,” although even that leaves open whether we are preparing dinner, generating a deployment system, or producing another metaphor about toast. Natural language is impressively flexible until flexibility enters the acceptance criteria.
Generative AI makes the Zeroth Law more important because it makes creation easier without settling necessity. Ask for a helper and you may receive a helper, an interface, a configuration layer, a test suite, and a cheerful README introducing the project to a world that had managed quite comfortably without it. The model is responding to the request. The request has already decided what success should look like.
If the first attempt fails, we ask it to continue. A local problem becomes a framework because frameworks offer more places to put the next correction. Soon there are agents coordinating agents, a custom message broker, and eleven pans on the stove. We originally wanted toast, but toast has become the reference implementation of our breakfast platform.
The economic change is real. A developer who expected an abstraction to take two weeks might spend an hour searching for an existing capability. When the abstraction can be generated in thirty seconds, searching feels like the expensive option. This comparison is persuasive only if the story ends when generation ends. Unfortunately, the compiler has no authority to close the account.
Generated code still needs to be understood, reviewed, secured, tested, operated, upgraded, and eventually removed. It can produce the visible trunk quickly. Consumers, operational assumptions, compatibility demands, and failure modes do not become free because the first draft arrived before the coffee. The pull request contains four thousand lines, nine interfaces, and documentation explaining why all nine interfaces are necessary. Two other models agree. We have achieved independent agreement about an assumption nobody asked them to challenge.
The useful prompt begins before implementation. Ask the model to recover the outcome behind the requested artifact, inspect the repository for existing capability, compare safe compositions, and consider whether obsolete behavior can be removed. Then ask for the smallest change that survives that inquiry, including its consumers and how it could later be replaced. This is less exciting than watching a service materialize, but excitement has never been a reliable compatibility policy.
AI can assist with search, comparison, impact analysis, and subtraction. It can also get those wrong, which is why “the model found no consumers” is a finding to investigate rather than permission to delete production state. The objective is not to replace construction with confidently automated non-construction. It is to stop rewarding output before determining what output would help.
Practice Without Starting a New Practice
“Build nothing” cannot mean refusing useful work while reciting philosophy in sprint planning. Sometimes the existing tool is dangerous, inaccessible, expensive, or incapable of meeting the requirement. Sometimes a new capability creates possibilities worth exploring before there is a mature business case. The law asks creation to survive examination; it does not require the future to submit receipts before arriving.
Begin by describing the outcome without naming the proposed apparatus. A person needs to know within five minutes when an event fails. That is a constraint. A notification service is one possible response, not yet a fact about the universe. An existing alert might satisfy it. Changing the process might remove the failure. Or the service might genuinely be needed, in which case we can discuss delivery guarantees instead of spending the first week naming notification abstractions.
Adoption must become discoverable. If nobody can find the consumers, nobody can confidently estimate the thing's mass or remove it safely. That may require usage records, explicit dependency declarations, or simply ownership that survives a team reorganization. These mechanisms also cost something. An inventory platform for three scripts can reproduce the problem it was commissioned to solve, now with a nicer search box.
Finding those consumers lets us ask what they actually depend on. Ideally, it is behavior we intend to preserve, not the particular order of an accidental output or the fact that a timeout currently returns success. Once enough consumers adapt to a bug, the bug receives tenure. Correcting it still matters, but now correction includes migration rather than a triumphant one-line patch and an afternoon of surprise.
That migration problem is why the exit belongs in the entrance discussion. Who will know when the last consumer has left? Can implementations coexist during replacement? Who owns extraction after the original team moves on? A tool without answers becomes a future Chesterton's fence, surrounded by people who suspect it is unnecessary but have discovered that suspicion is not a rollback plan.
For an experiment, the extraction problem can start before anyone admits there is a product. A proof of concept is scaffolding, not a constitutional amendment, and it needs a point at which somebody decides whether it continues. Its expiry should trigger review, not an unattended deletion while consumers are using it. If it succeeds, keep the parts the evidence supports. If it fails, remove it before a copied example becomes somebody else's reason that removal is impossible.
Subtraction also needs to count as work. An architecture review can ask which obligations disappear, and a planning discussion can recognize an avoided migration as an outcome rather than a missing deliverable. Otherwise the rational career move is to build the thing, become its indispensable expert, and later receive recognition for managing the complexity one introduced. This need not involve bad intentions. The incentives are capable of arranging it without assistance.
Most importantly, distinguish support from waste. Tests, documentation, observability, and migration paths are not leaves we can remove because customers only eat the fruit. If the tool must exist, responsible support may be part of its irreducible cost. The Zeroth Law is not a discount code for shipping unsupported software. It is a reason to consider that cost before promising the object at the tip of the cone.
The harder question is whether we can allow a needless process and its corresponding demand to cease. Engineers are good at improving execution, preserving compatibility, and retaining just in case. Ceasing asks us to relinquish something we know how to manage, perhaps something we built ourselves. It may also ask us to admit that a very successful quarter produced a very maintainable obligation.
First, Build Nothing
Tools are made from tools, just as ideas are made from ideas. Every artifact inherits languages, protocols, libraries, infrastructure, and accumulated knowledge. Once adopted, it changes what later systems can assume. A convenient output becomes an input somewhere else; an experiment becomes a precedent; a workaround becomes the example used to train the next engineer. Every tool is both fruit and seed, including the ones we were quite sure would remain internal.
This is why creation is not local and removal is not deletion. Deleting the repository can leave its historical data, contracts, procedures, and expectations alive elsewhere. The thing may be gone while everything still holds its shape. We have removed the apple dispenser and retained an organization that arrives every morning carrying a bowl.
Engineering begins by looking beyond the visible artifact to the conditions it requires and the conditions it will create. Build when the actual constraint warrants it. Make the result correct, support it honestly, and preserve a practical way for it to stop existing. But before turning a request into another part of the world, leave room for the possibility that no new part is required. An empty repository is not necessarily an unfinished project; sometimes the question was answered before it needed one.
Postscript: The Tree Makes an Objection
I confess I have rarely encountered a proper postscript in an actual letter outside literature, so this is quite exciting. It is also necessary because the tree remains standing after the argument, still producing apples with an apparent disregard for my excellent concerns about its architecture.
The tree pays much of its growth cost before producing fruit repeatedly. It can shelter animals, feed pollinators, stabilize soil, and create more trees. Some of what appeared to be overhead supports several outcomes at once. The dependency cone is large, but the returns do not stop at my six bites over the kitchen sink. I was not wrong to notice the cost. I was wrong if I thought noticing it completed the evaluation.
The tree would have had difficulty passing a conventional architecture review before its first apple. Years of growth, underground dependencies, seasonal availability, third-party pollination, and a deliverable whose principal consumer discards the reproductive payload: please simplify and resubmit. A procurement team might recommend buying apples instead, thereby moving the tree outside the diagram and announcing that the dependency had been eliminated.
This is the limit of the law. A dependency cone reveals the scale and character of an investment; it does not prove the investment should never be made. Some artifacts are valuable because they enable outcomes nobody could fully specify beforehand. Their uncertainty should be acknowledged, their continuation examined, and their support funded, rather than treated as either permission for everything or an argument for nothing.
Do not build what need not exist, but do not confuse “I cannot yet justify this” with “this need not exist.” Aggressive restraint can prevent useful compounding just as enthusiastic construction can produce permanent housekeeping. The question is not how to avoid ever being wrong. It is how to make a decision whose benefits, obligations, and grounds for reconsideration remain visible after the rocket emoji has scrolled away.
The tree can stay. I am less certain about the dashboard that reports whether the tree is still there, but apparently three teams consume it now.
This essay was written and revised with the help of AI. No new service was required, although a Markdown file did survive examination.
Top comments (2)
The line about AI making creation easier without settling necessity really stands out. It’s becoming easier to generate code, tools, and entire systems, but every one of them can create new things to maintain.
Sometimes the best engineering decision is finding out you don’t need to build anything new in the first place.
The apple/tree metaphor is brilliant. It perfectly captures the "dependency cone" problem—we estimate the two days of coding, but ignore the years of maintenance, compatibility, and documentation that the artifact will require.
The point about "construction has excellent visibility" hits hard. We can count commits and PRs, but we can't easily measure the value of the meeting where someone asked "do we actually need this?" and killed the project before it started.
One thought on the AI section: since LLMs make construction nearly free, the "Zeroth Law" becomes even more critical. It's so easy to generate a 4,000-line PR just because you can, completely bypassing the step of asking if the abstraction is actually necessary. Have you found any practical way to force that "do we need this?" checkpoint into an AI-driven workflow, or is it still entirely on the human to remember to ask?