Action at a Distance
The most honest test of a codebase is how far you have to look to be sure a small change is safe.
Here is a function you would sign off without a second thought. It takes a price and gives you back a price, twelve lines, nothing surprising in it, and you can see every branch at a glance. So you change one of the lines, carefully, and you ship it. Then three weeks go by and invoices start going out wrong in a country you have never been to. The function did exactly what it said it would. But the function was never the whole story. Off in some other file you have never even opened, a flag that got set once during start-up had decided that this function rounds differently for one particular currency, and there was nothing on your screen that could have warned you. You read the code in front of you and you understood every character of it and you were still wrong, because what the code actually does was never written down where the code is.
So start with the one question that matters when you go to change anything. To convince yourself it's correct, how far from this screen do you have to look. In a healthy system the answer is "the screen". In most systems the honest answer is "nobody knows", and that answer is the true size of the thing you are dealing with, not the line count.
Physics has a name for an influence that crosses a gap with nothing in the middle to carry it, and it bothered Einstein enough that he reached for the supernatural to insult it: spukhafte Fernwirkung, spooky action at a distance. He couldn't accept that measuring one particle over here might pin down the state of another one over there with no thread running between the two. Our version isn't some deep truth about the universe. It's a habit, and we keep reaching for it because it's handy. A variable that gets changed three modules away. An effect that fires the moment a file is imported. The accidental order that two functions happen to run in. Or take the logging helper that looks like all it does is format a string, and then the first time you call it the thing quietly opens a network connection and registers a shutdown hook, so reaching for a way to print one line has gone and changed how your whole program dies. Cause sits in one place and the effect shows up in another and there is nothing on the line between them to say the two are even connected. Einstein hated finding this in nature. We build it on purpose, and we have it done by Tuesday lunchtime.
We've been here before, and we even won once. Back in 1968 Edsger Dijkstra sent a short letter to a computing journal arguing against the goto, the instruction that lets control leap from anywhere to anywhere. The famous title, "Go To Statement Considered Harmful", wasn't even his. An editor called Niklaus Wirth supplied that one, and Dijkstra's own had been the duller "A Case Against the Goto Statement". His real argument had nothing to do with a keyword. It was that a person can only reason about a program if they can put a finger on a line and say what is true here, and the goto wrecked that, because you could no longer tell how you had got to that line, and once you have lost how you got somewhere you have lost everything. We spent a decade stamping the goto out. And then we went and rebuilt the same thing out of global state and hidden effects that fire in an order nobody chose. The goto jumped through your control flow. Action at a distance jumps through the whole system, and nobody ever bothered to write it a letter.
On the eighteenth of November 2025 this exact shape took out a large slice of the internet for several hours. The first link in the chain had been forged earlier the same morning and it looked like nothing. An engineer adjusted some permissions on a database. That made a routine query start returning rows it had always quietly skipped, which roughly doubled the size of a configuration file that the system rebuilt every few minutes. The file was loaded by the proxy sitting in front of something like a fifth of the world's web traffic, and buried deep in that proxy was a line that had always assumed the file would never grow past a certain size. It did grow past it. The proxy fell over, and down with it went a long list of things nobody would ever think to connect to a database permission: sites, sign-in pages, dashboards. Cloudflare later called it their worst outage since 2019. Read the chain back through and not one link is a mistake on its own. The permission change was sensible. The query was correct. The proxy's assumption had been a reasonable one the day somebody wrote it. The wrongness wasn't in any single step. It was living in the gaps between them, along the wires nobody was looking down, and that is where it always lives, and it is the part that nobody is actually assigned to read.
This is the heaviest thing you pick up when you go to change software, and you pick it up before you have typed a single character. When the behaviour is decided somewhere else, reading the code in front of you stops being enough. You have to reconstruct all the invisible context that really governs it and then hold the whole lot in a head that was never built to hold it, working the entire time with a low hum of dread that you have missed a wire somewhere. That is how a one-line change can eat a whole day. It is why there is always one module nobody will go near, and why on the worst systems the move that feels safest is to make no move at all. The code didn't get more complicated. What got bigger was the amount you have to know to change it safely, and that quantity is the real weight of a system. It is the thing that decides whether a tired person can work on the system without bringing it down.
The cure isn't cleverness. It is nearness. Keep cause and effect within arm's reach. The control flow and the rules that govern it want to be close enough that you can see them together. Every dependency a function needs should be handed to it in plain sight instead of reached for in secret. No bit of code should be quietly steering another from the far side of the building. Do that and a change can be checked by looking only at the change, and looking only at the change is the one thing a real person can actually manage on an ordinary afternoon with whatever attention they have got left. So next time an innocent-looking edit leaves you uneasy, don't answer it with more care. Measure how far from the screen you had to look to be sure of it. If that distance frightens you, then the bug you should be afraid of isn't in the line you touched. It is in the distance.
In the manifesto, this is tenet (I).
Sources
- [Cloudflare Outage 2025] Cloudflare outage on November 18, 2025 (official post-mortem). 2025. https://blog.cloudflare.com/18-november-2025-outage/. A database permission change doubled a generated config file, crashing the proxy network-wide; tenet I.
- [Constantine et al. 1974] W. P. Stevens, G. J. Myers & L. L. Constantine, "Structured Design". IBM Systems Journal 13(2), 1974. https://dl.acm.org/doi/10.1147/sj.132.0115. Coupling and cohesion, the structural frame behind tenet I's symptoms; tenet I.
- [Dijkstra 1968] Edsger W. Dijkstra, "Go To Statement Considered Harmful". Communications of the ACM 11(3), 1968 (title supplied by editor Niklaus Wirth). https://dl.acm.org/doi/10.1145/362929.362947. The founding case against unstructured jumps and reasoning about distant program state; tenet I.
- [Einstein 1947] Albert Einstein, letter to Max Born (3 March 1947), 'spukhafte Fernwirkung' / 'spooky action at a distance.' Pub. The Born-Einstein Letters, 1971. https://en.wiktionary.org/wiki/spooky_action_at_a_distance. The 'spooky-action' colouring of remote-effect abstractions; tenets I, II.
One of a series of field notes on building software for the way minds actually work: tired, distractible, ordinary, and now partly machine. They all lead back to the manifesto behind them, The Shape of the System.