It's Halloween, which means the internet is full of horror stories. Developers have their own kind. Ask anyone about the scariest thing they've found in a codebase and nobody mentions a clever exploit or a race condition that took a week to catch. They mention something small, quiet, and old. Something that's still there.
Here are five of those. None of them is a bug. All of them are scarier than most bugs.
1. "Temporary"
The single scariest word you can grep for.
Every long-lived codebase has a fix that was supposed to last a week. It has a comment saying so — // TEMPORARY, remove after the migration — dated four years ago. The migration finished. The fix stayed. By now three other features depend on its exact behavior, including the part where it's wrong, and removing it is a project nobody will approve because "it works, don't touch it."
The people who wrote the software that failed at Y2K weren't careless. They wrote temporary code in the 1960s and 70s — who would still be running this in thirty years? — and the code outlived the question. Temporary code doesn't ask permission to become permanent. It just waits.
2. The silent default
A bug screams. A default whispers.
The scary configuration isn't the one that's set wrong — that one shows up in testing, eventually. It's the one nobody set at all, because the default quietly did something reasonable on the developer's machine and something else in production. Debug mode that defaults to on. A retry count that defaults to forever. A timeout that defaults to "no timeout," which is a way of saying the timeout is your uptime.
You can't grep for a missing line. That's what makes it frightening: the reviewer's eye slides over the thing that isn't there.
3. The comment that lies
No comment is a gap. A wrong comment is a trap.
// returns null if the user has no subscriptions — and it doesn't, not since the refactor two years ago, but the comment survived because comments don't fail CI. Every developer who reads it writes code against a function that doesn't exist anymore. The comment isn't documentation; it's disinformation with good formatting.
I've started treating every comment I read as an unverified claim. It's a sad way to read code, and it has saved me more than once.
4. The test that always passes
A test suite with zero failures feels like safety. Sometimes it's a costume.
There are tests that assert the mock returns what the mock was told to return. Tests wrapped in a try/except that swallows the failure. Tests that were disabled "for the release" — there's that word again — and never came back. The suite is green, the badge is green, and the confidence is fictional.
Bugs are honest: they break things. A hollow test does something meaner — it teaches you to stop looking.
5. The script only one person understands
Somewhere in the deploy pipeline there is a file — it's usually a shell script, it's always named something like final_deploy_v2_REAL.sh — that exactly one person can read. It works. Nobody knows why. It parses a log with awk in a way that depends on the locale, and it has survived three attempts to replace it because every attempt found one more thing it quietly does.
This isn't a knowledge problem. It's a horizon problem: the day that person is on vacation and the script breaks, the whole company gets a very educational afternoon.
The pattern
Look at the five and a pattern shows up: none of them is scary because of what it does. They're scary because of what they hide. A bug is a visible monster — you can point at it, assign it, fix it, close it. These are the opposite. They look like stability. The temporary fix works, the default behaves, the comment reads well, the suite is green, the script runs.
Until the one night they don't — and it's never an afternoon, is it.
So, since it's the season: what's the scariest thing you've found in a codebase? The older and quieter, the better. I have a feeling the comment section can do better than my five.
Top comments (0)