The Blast Radius Was Four Rows

A while back I read an incident report that described the “blast radius” of a “catastrophic” data issue. I kept reading, looking for the part where something exploded. The actual damage: four rows in a reporting table carried a stale value for about an hour, and one dashboard showed a wrong number until the next refresh. Nobody was blasted. There was no radius.

I want to talk about the words we use in this industry, because I think we have a habit of choosing them for how they make us sound rather than for what they say. I am not the first person to write about this, I will not be the last, and I am certainly not the best-researched voice on it. But given how consistently we reach for drama we have not earned, an attempt at change seems worth making.

Two ways to miss

Technical vocabulary fails in two opposite directions, and both failures have the same cost: the reader learns less than they should.

The first failure is aggrandizement. We borrow words from war zones and natural disasters to describe office work. Blast radius. War room. Kill switch. Death spiral. Thundering herd. Postmortem, for a meeting where everyone involved is alive and drinking coffee. We nuke tables, we take flak, we fight fires. A service does not stop; it dies, it crashes, it is brought to its knees.

The second failure is vague euphemism. This one runs the other way: instead of inflating, we dissolve. Code is not slow; it is “unperformant.” A design is not wrong; it is “sub-optimal.” We did not cut features because we ran out of time; the delivery was “de-risked by streamlining scope and focusing effort toward the low-hanging fruit.” There is a wonderful taxonomy of this dialect at IT Shambles^[1] that I cannot improve on, and an English Stack Exchange answer on “unperformant”^[2] that makes the case plainly: adding poorly understood words to documentation decreases the one thing documentation exists to provide.

These look like opposite sins. One shouts, one mumbles. But they are the same disease: in both cases the words carry attitude instead of information. “Blast radius” tells you the author found the incident exciting. “Sub-optimal” tells you the author found the truth uncomfortable. Neither tells you what happened.

What the dramatic words actually cost

I used to think the militaristic vocabulary was harmless fun, and in a hallway conversation it mostly is. The trouble starts when it reaches people who make decisions based on your words rather than on the system itself, which describes most readers of an incident report.

An executive who reads “catastrophic” does not know it means four rows. They know what “catastrophic” means in every other context they have encountered it, and they will act accordingly: escalations, standing meetings, a sudden appetite for vendor tools. You editorialized, and now you get to live inside the editorial.

There is a second cost, and it compounds: severity inflation works much like alert fatigue. If a stale dashboard is catastrophic, what word is left for the day the log chain breaks and the business actually loses data? You have already spent the vocabulary. Teams that describe every incident in disaster language end up with readers who discount all of it, which means the one report that genuinely needs urgency arrives pre-discounted.

I wrote recently about overclaiming certainty,^[3] the gap between how sure someone sounds and how sure the evidence warrants. This is the same gap on a different axis. Overclaiming severity is the distance between how dramatic something sounds and how dramatic it was. Both are rewarded in the moment, because loud reads as important the same way confident reads as competent. And both quietly spend a credibility budget you will eventually want back.

What the vague words actually cost

The euphemistic register looks safer, which is why people retreat into it. It is hard to get in trouble for calling something sub-optimal. But vagueness has a price too, and it is paid by whoever has to act on your words.

“The query is unperformant” gives the next engineer almost nothing to act on. “The query takes 40 seconds because it scans a 200 million row table for every request” gives them a starting point. The vague version is not shorter, not kinder, and not more professional. It is just less useful, dressed as more.

Worse, the vague register is where accountability goes to disappear. “Mistakes were made” is the canonical example, but our industry has its own dialect: “the resources ringfenced for the project are not ideally correlated with the required skill set” is a real sentence someone said out loud, and it means “we did not staff this properly.” When every uncomfortable fact gets sanded down before it reaches the page, the page stops being worth reading.

A third, quieter failure: borrowed precision

There is a subtler cousin to both of these, and it runs in yet another direction: taking a word that has an exact technical meaning and spending it in the loose vernacular sense.

“The errors are random” is the classic. In my experience, the person who says this rarely means random. They mean intermittent, or unpredictable, or I-have-not-found-the-pattern-yet, which is a statement about the observer, not the system. To anyone who works with data, “random” is a strong claim: uniform distribution, no correlation, each occurrence independent of the last. Errors that happen every day at 2 AM are not random; they are scheduled, and that pattern is a diagnostic clue the word “random” would have thrown away. There is a good English Stack Exchange discussion of this one,^[4] which points out that the table names MyTable and SomeColumn are arbitrary, while d$fv$5vmZO^zc90h7 is random, and the two tell you very different things about how they were produced.

“Exponentially” gets the same treatment. “Performance degraded exponentially” nearly always means “got much worse,” with no doubling behavior anywhere in the data. Exponential growth is a specific, measurable shape, and it matters: it is the difference between “we have a year” and “we have a week.”

To be fair, the etymology cuts against the pedants here: the loose sense of “random” (haphazard, without aim) is centuries older than the statistical one. So I do not treat this as a correctness scold. It is a precision plea: in a technical context these words carry testable claims, and using them loosely spends information the reader thought they were receiving. If you mean arbitrary, “arbitrary” is right there. If you mean intermittent, say intermittent, and then say what you have ruled out.

The test: information or attitude

To be clear, this is not an argument against jargon. Jargon that compresses a precise concept is one of the best tools we have. Deadlock, race condition, log sequence number, write-ahead logging: each of these replaces a paragraph, and practitioners decode them consistently. That is the test. A good technical term carries information; a bad one carries attitude.

The compression only works, though, when the reader holds the codebook. Acronyms are the sharpest version of this problem: “check the AG before failing over, the RPO depends on it” is efficient between two DBAs and a locked door to everyone else in the room, including the people approving the budget. Worse, the codebook is not even internally consistent; in SQL Server alone, DAC means both “dedicated administrator connection” and “data-tier application,” so the compression can fail between two insiders too. Speaking in unexpanded acronyms rarely comes from a desire to exclude, but exclusion is what the listener experiences, and “elitist” is the word they attach to it. That problem deserves more room than a paragraph, so I will return to it in a separate post.

“Deadlock” passes: it names a specific, well-defined condition, and calling it something gentler would lose meaning. “Blast radius” fails: it adds zero precision over “impact scope” and imports a connotation of violence that the facts do not support. “Unperformant” fails from the other side: it sounds technical while specifying nothing, not even slow-compared-to-what. And “random” fails in context: the word passes the test on its own, which is exactly why spending it on “I have not found the pattern yet” wastes it.

Substitutions I actually use

Here is the working list I apply to my own incident reports, root cause analyses, and reviews. None of these are about softening the truth. Several of the preferred terms are harsher, because they are specific.

The pattern in the right-hand column is consistent: prefer the word that makes a follow-up question easy. “Impact scope” begs for “how many rows, how many users, how long?” “Blast radius” begs for nothing; it has already told you how to feel.

Writing the report

When I write a root cause analysis now, I try to hold to three rules.

First, numbers over adjectives. “Three of twelve nodes were unavailable for 40 minutes” will survive contact with any audience I have met so far. “A major outage crippled the cluster” will not survive contact with the person who checks.

Second, name the actor when you know it. The passive voice is the load-bearing wall of the euphemistic register. “The table was dropped” and “the deployment script dropped the table” differ by five words and a good deal of investigative work.

Third, spend strong words only when the facts back them. I still write “severe” sometimes. When I do, the next sentence is the measurement that earns it.

I have made this mistake in the other direction too, editorializing in the small: I once called myself dumb in a code comment^[5] where “this cursor is intentional, here is why” would have served the next reader better. Attitude instead of information, at row-by-row scale.

None of this will fix the industry, and I hold no illusions that one more post on plain language moves the needle far. But every report is a small choice, and the accurate version costs little beyond the fun of sounding like a war correspondent. It turns out the reader would rather know what happened.

(In the spirit of full disclosure: an earlier draft of this post claimed that a single word choice was “the entire diagnosis.” It was not. This is harder than it looks, which may be the most honest sentence in the piece.)

Have a favorite example of tech vocabulary that says less than it seems to? I would enjoy hearing it on Bluesky or LinkedIn.

References

1. Bad Language I – IT Shambles. A field guide to business-technology gibberish: buzzwords, words ground free of meaning, and the clumsy military metaphors this post borrows its complaint about. Informative and very funny. ↩
2. Is there a word/phrase for “unperformant”? – English Stack Exchange. The answer arguing that “poorly performing” beats “unperformant” because ease of understanding is the entire job of documentation. ↩
3. Hedging Like a Witness Under Oath – the companion piece to this one, on overclaiming certainty rather than severity. ↩
4. Why does common usage of “random” feel so incorrect? – English Stack Exchange. Includes the etymology showing the loose sense is older, and the arbitrary-versus-random table name examples. ↩
5. I Called Myself Dumb in a Code Comment. I Was Wrong About the Cursor. – the same mistake at comment scale: attitude where information should be. ↩