People call me a perfectionist. Usually with affection, sometimes with a sigh, occasionally in the tone you’d use about a relative who irons their socks. The same people, often in the same breath, say the other thing: his software runs for years and doesn’t break.
They think those are two observations. They’re one observation, misdiagnosed.
The Counter-Evidence
If I were a perfectionist, I could not have shipped the parser.
There is a parser of mine running in production on someone else’s compute cluster. I wrote it by hand, years ago, in an afternoon of squinting at log lines that were — I want to be precise here — not valid anything. A logging format with another format smuggled inside it, unescaped quotes, literal tab characters inside quoted values. No decoder on earth parses those lines. So the parser rips the smuggled blocks out with string markers first and parses the wreckage that remains.
It is ugly. It has a known failure mode I understood when I shipped it — certain malformed lines get dropped, whole. It writes its results to a plain SQLite file sitting on a disk. And it tracks manufacturing milestones for a cell therapy, which is to say: every line it catches genuinely matters, and there are about seventeen of them a day, swimming in a firehose of four hundred thousand lines of noise.
It has run, untouched, for years. Through cluster restarts, through log format drift at the edges, through everything. A perfectionist could not have shipped that parser. A perfectionist would still be refactoring it.
So the label is wrong. But the observation under the label — the relentlessness people are actually detecting — is real. It’s just aimed at something else.
Where Software Actually Breaks
Software does not break where the code is ugly. If it did, nothing of mine would survive a fortnight.
Software breaks where its model of reality was wrong. The input that couldn’t happen. The load shape nobody profiled. The machine that dies mid-write. The job that runs at a volume no one imagined because no one looked. Every production incident, dig far enough, is a belief about the world that turned out to be false — discovered at the worst possible moment, because that’s the only moment undischarged beliefs get discovered.
Breakage is deferred assumption-checking, paid at 3 AM, with interest.
Ugly code built on checked assumptions runs for years. Beautiful code built on unchecked assumptions is a pager with extra steps. Once you see the split, the so-called perfectionism resolves into something much more specific: I am cheap about polish and extortionate about calibration. I will ship a hack without blinking. I will not let an unmeasured claim survive the afternoon.
A Day of Zooming In
Yesterday I spent an entire day with, essentially, one monitoring graph. It’s the best portrait of the method I can offer, because the graph kept correcting me.
First read: a dramatic spike in log volume, twenty-five times baseline, once a day. A dump, clearly. Some job flushing its buffers.
Then I pulled the companion metric and the units changed the story. Then I zoomed the time range, and the resolution changed it again: the “spike” was a plateau — a flat-topped, hour-long, sustained run at fifteen times the baseline, recurring every few hours. The two-week overview had aliased hour-long plateaus into innocent needles. A downsampled panel will lie to you with a straight face; it’s not wrong, it’s just answering a smaller question than the one you asked.
Then per-source breakdown, and the culprit got a name: a scheduled cleanup job — the kind that deletes old files and narrates every single deletion into the log. Sixty million lines per run. Between it and its sibling on the QA side, roughly half the logging estate’s entire daily volume turned out to be one janitor describing its own mopping. The genuinely important lines — those seventeen milestones — were a rounding error inside a rounding error.
Somewhere in the middle of this, a machine I couldn’t reach turned out not to be down at all; my conclusion was wrong, the box was fine, and the actual cause was an operating-system permission three layers away from where I was looking. I only found it because someone asked are you sure? — and the correct answer to that question, always, is to go find out. Reality had disagreed with my conclusion, and when reality disagrees with your conclusion, reality is right. It has a perfect record.
By evening, every number in the design I was building had one of exactly two properties: it traced to a measurement, or it was labeled unmeasured — in writing, in the report, in a section literally titled be honest. Not a single “should be fine.” Should-be-fine is where the 3 AM pages live.
Polish the Model, Not the Artifact
That’s the whole method, and it fits in a sentence: ship rough, measure precisely.
The artifact can be a duct-taped parser feeding a flat file. The model — what the load actually is, what the failure modes actually are, which lines actually matter, what happens when the box dies mid-write — gets the perfectionism. All of it. The polish budget is finite; spending it on the code is spending it on the part that was never going to page you.
And here’s why this produces the runs-for-years property that gets mislabeled as perfectionism: the ugly parser survives because I had read the ugly lines before I wrote it. The blocks-before-parsing trick exists because I had personally seen the unescaped quotes. Its assumptions were paid for up front, in daylight, at my desk — instead of at 3 AM, in production, with a customer watching.
The cleanup job is the same story at estate scale. Discovered yesterday, it’s a paragraph in a report with a mitigation attached. Undiscovered, it was eighteen months away from being somebody’s retention crisis — the mystery cost spike, the emergency meeting, the consultant. A year-two incident, discovered in year zero, costs a paragraph. The same incident discovered in year two costs a war room. Calibration is just buying incidents at the year-zero price.
The Prescription
If people call you a perfectionist and your software breaks anyway — you’re polishing the wrong thing. Redirect the compulsion:
Before you build: what did you actually measure, versus inherit, versus assume? Which single number, if wrong, changes the design? Go get that number. It’s usually one query away, and the query is usually cheaper than being wrong.
When you look at a graph: zoom in before you conclude. Aggregated views answer smaller questions than the ones you ask them. The spike is a plateau. The plateau is one job. The job has a name.
When you write it down: split every claim into measured and unmeasured, and label the unmeasured ones out loud. The label is not an admission of weakness; it’s a map of where the 3 AM pages are hiding.
When reality disagrees with your conclusion: reality is right. Are you sure? is not an insult. It’s the cheapest debugging tool ever invented.
And ship the hack. Genuinely. The hack that ships teaches you what the real system needs to be; the beautiful system that doesn’t ship teaches you nothing and breaks anyway, later, on assumptions nobody checked because everyone was busy making it beautiful.
Not a perfectionist. The code can be ugly. The model cannot be wrong.
There’s an encyclopedia where software principles get the roast they deserve, and a mythology where these ideas have been arguing with each other for a hundred and fifty episodes.
See also:
- Gall’s Law Got Cheap — Ship the probe, keep the ledger. The hack-shipping half of this essay, with its own discipline.
- Software Dies of Obesity, Not Starvation — What happens when the polish budget goes to the artifact anyway.
- The Rewrite Trap — The industrial-scale version of polishing the wrong thing.
- Twenty Words — Where the written-down judgment lives, and who executes it at 3 AM so you don’t have to be awake.
- Why Every AI-Assisted Codebase Will Collapse (Unless Someone Loves It) — The love is aimed at the model too.