The folder everybody has
Forty files. A few are genuinely useful and get run monthly. Most were written for one afternoon in 2023 and solved something that no longer exists. Several do nearly the same thing, and nobody remembers which of them is the one that works.
Writing throwaway scripts is not the failure. They are the right response to a one-off problem, and treating every ten-line loop as software would be its own waste.
The failure is not noticing when one of them stopped being a throwaway.
The transition nobody marks
It happens quietly, in one of three ways:
- Somebody else runs it. You send it to a colleague during an incident.
- It gets referenced in a runbook. Now it is part of a procedure, and the procedure is followed by people who have never read the script.
- It goes on a schedule. Now it runs unattended, and its failures are silent.
At that moment it became infrastructure, and nothing about it was re-examined, because the transition has no ceremony. The script that was fine when only its author ran it is now being trusted by people who cannot read it and did not choose it.
What makes a script safe for somebody else
Not elegance, and not tests. Five properties, and each maps to a way scripts hurt people:
It says what it does before it does it. Run with no arguments, it prints what it is for and what it will touch — rather than starting. The most dangerous script is the one that begins working the moment you type its name.
It is read-only, or it says loudly that it is not. Most operational scripts should only gather. For the ones that change something, dry-run should be the default and acting should require a flag — because the person running it at three in the morning inherited the command from a runbook and has not read the source.
It fails completely rather than partially. A script that processes forty devices and dies at device twelve, having half-configured device twelve, is worse than one that refuses to start. Partial success is the failure mode that costs the most, because the estate is now in a state nobody designed.
It does not depend on its author's environment. The alias, the path, the credential already in their shell, the assumption that python means version three. Somebody else runs it and gets an error — or worse, a result that looks complete and is not, because the credential they had granted read access to only half the estate.
Its output can be trusted or is obviously untrustworthy. Silence must never mean success. An empty result and a failed lookup should not look the same, because a check whose input silently came back empty reports success for work it never did.
Say why it exists, in the file
The code says what it does. Only a comment can say why it exists and when it stops being needed.
# Compares pool member state across the four sites. Exists because the
# platform's own view is per-site and the 2026-03 incident turned on a
# member being down in one site only. If the vendor ships a cross-site
# view, delete this.
Four lines, and they contain the two things that determine the script's future: the reason it was written and the condition under which it should die. Without them it will be inherited, half-understood, and kept forever by people who assume somebody had a reason.
This is the same instinct as recording a changed value's reason in the template it came from — a fix or a tool with no rationale attached invites the next person to remove it or, worse, to preserve it long past its usefulness.
What to delete
Deletion is the underrated half, because every script kept is a thing somebody will find during an emergency and trust.
- Scripts that encoded a workaround for something now fixed. They will still run, and produce a wrong answer confidently.
- Scripts nobody has run in a year. If it mattered, it would have run.
- The three that nearly do the same thing. Keep the one that works; the ambiguity itself is the hazard, because on a bad night somebody will pick wrongly.
- Anything whose output nobody can interpret any more.
The test is not "might this be useful?" — everything might. It is "if somebody finds this in an emergency and runs it, are they better off?"
The line between a script and a tool
Some scripts earn the promotion: run by several people, relied on in procedures, or producing something people act on. Those want the things a script does not — an interface somebody can discover, validation of input, output that explains itself, and a home that is not one person's laptop.
Most do not earn it, and forcing them through that gate is how a useful ten-line loop becomes a project nobody finishes. The promotion should follow the usage, not precede it.
Four questions before a script stops being yours
Asked at the moment somebody else is about to run it — which is the moment it changes category:
- Does it say what it will do before doing it?
- If it changes anything, is dry-run the default?
- Does it fail loudly and completely, and can silence be mistaken for success?
- Does it work in somebody else's environment, with somebody else's access?
And the fifth, which is the same test the whole of this part keeps arriving at: could somebody run this at three in the morning, from a runbook, without you? If not, the honest options are to fix it or to keep it to yourself — but not to send it and hope, because it will end up in a procedure either way.