Logical fallacies

Claim.

The utility bill charges for water twice.

You always mix up numbers — and now you're the one counting.

Why it is a fallacy.

Past mistakes in arithmetic don't change the bill. The lines are either duplicated or not, and anyone who opens the bill can see it.

At work.

In review, a comment about a race on a shared cache is dismissed with “you've been here three months, you haven't seen our load”. The reviewer's tenure adds no synchronisation. The race either reproduces in a test with two parallel writes or it doesn't.

A claim and its author are different things to check. Ad hominem swaps the question “what does the claim rest on” for “who said it”. Facts about the person matter when the claim rests on their testimony or expertise. But then the conclusion is “we need an independent check”, not “the claim is false”. The sign: remove the remark about the author and nothing is left of the objection.

Claim.

Don't eat on the move — you get half a day of heaviness afterwards.

You finished a sandwich on the way in yesterday.

Why it is a fallacy.

The speaker's behaviour doesn't change the link between eating on the go and a heavy stomach. It only shows they don't follow their own advice.

At work.

The proposal “a regression test for every bug fix” is met with “you merged a hotfix without a test yesterday”. The author breaking the rule is a separate topic about equal exceptions. Whether a regression test catches the bug coming back is untouched by that answer.

A person's inconsistency is a fact about the person, not about the norm. If the adviser doesn't follow the advice, that speaks to their discipline. The case for the advice stays the same. In a dispute about applying a rule fairly, pointing to exceptions is relevant: there the question is not whether the norm is true but whether it is applied equally. The question of the dispute decides it: “is the rule right” or “is it the same for everyone”.

Claim.

I suggest we check the card spending once a week.

So now we log every pack of gum and live with a calculator in hand.

Why it is a fallacy.

What gets refuted is tracking every purchase, which nobody proposed. Nothing is said about the weekly check — how long it takes and what it gives.

At work.

“Mandatory review for billing changes” turns at the meeting into “you want to approve every line and stop releases”. The discussion moves to stopping releases. Whether the scope is billing only or the whole repository is never clarified.

What gets refuted is a wording the author never used. The substitutions vary: “sometimes” becomes “always”, a precise criterion becomes a vague one, the position is taken from its weakest supporter, a quote loses its caveats. The sign: victory is declared, and the original wording was never repeated. The test: restate the position so that its author agrees with the restatement.

Claim.

Salt is better added closer to the end of cooking.

That's your grandmother's folk wisdom, half her advice came out of nowhere.

Why it is a fallacy.

The origin of the advice tells how well it was tested. Whether vegetables soften differently in salted water is shown by the pot, not by the source's biography.

At work.

“Marketing proposed this caching scheme, so technically it's nonsense.” The source hints at whose interests are behind the proposal but does not say what happens to the cache when the price changes. With a dataset, citing the source is legitimate: where the data came from is a question about the sample itself.

The origin of an idea tells how it was obtained: who had an interest, how carefully it was checked, what data there was. That affects what to check first but does not replace the check. The fallacy begins when, after naming the source, nobody looks at the content. The exception is data provenance: where a dataset comes from directly decides how representative it is and whether it may be used.

Claim.

That gym is inconvenient for me: it's forty minutes each way.

Really you're just too lazy to train, the time has nothing to do with it.

Why it is a fallacy.

A map checks the journey. “Laziness” is an attributed state the person never mentioned. Arguing with it doesn't shorten the forty minutes.

At work.

In an incident review: “the on-call engineer didn't escalate because they were afraid of looking incompetent.” The reviewer knows the outcome. At three in the morning the engineer had partial metrics and a runbook without the needed branch. Until the person and the timeline confirm the cause, it is the observer's guess. It gets in the way of finding the real process defect.

The observer describes another person's experience from their own position. They know the outcome and context the person did not have at the time, and attribute their description to the person as fact. In a dispute this is an attack: the opponent is told what they really feel or mean, and the attributed view is refuted. Only what was said can be checked. Motives are a hypothesis that the person, not the observer, can confirm.

Claim.

We don't need a water filter: the test says the water here is fine.

Sure, you just grudge the money, that's why you say it.

Why it is a fallacy.

Not wanting to spend money explains why the conclusion suits the person. The water's composition is decided by the test, not the budget. An interest is a reason to order your own test, not to treat theirs as false.

At work.

“He pushes the managed database because he used to work for a cloud provider.” His past job is a reason to ask him for a TCO estimate and a self-hosted option. It is not a reason to treat his numbers as wrong.

A conflict of interest is a reason to check, not a verdict of falsehood. The correct form: testimony from an interested party is not independent, so it needs re-checking. The fallacious form takes an extra step and replaces the re-check with a ready conclusion. The sign: after the interest is named, nobody checks anything and the question counts as settled.

Claim.

That's the second time you forgot the parcel, it's been sent back.

As long as you're raising your voice, I'm not discussing this.

Why it is a fallacy.

The parcel went back to the sender however loud the conversation was. Tone can be discussed, as a second topic, not instead of the first.

At work.

In an incident channel, a message in caps “the production key is in a public repository” gets the reply “let's not panic”. Calm communication is a reasonable norm for the retro. Meanwhile the key still works: first revoke and rotate, then talk about tone.

Delivery and content are independent. A request to speak more calmly is legitimate as a separate conversation about norms. But it doesn't answer the claim or change whether it is true. The fallacy is making a calm tone the condition for discussing the substance. Then any indignation devalues what is behind it, and the calmer side gets a free way not to answer.

Claim.

This way of washing windows without streaks works.

That's advice from the blog where colds are treated with onions.

Why it is a fallacy.

A shared source transfers no property to the method. The window is either streaky after cleaning or not, and you can see it without knowing the blog's other advice.

At work.

“This library is used by the company that leaked user data, so it's unsafe.” Transfer needs a channel: a common maintainer, a compromised supply chain, a shared vulnerable dependency. You check CVEs, the release signature and a code audit, not the list of users.

If two things share one feature, their other properties don't transfer. For the association to mean something, a mechanism has to be named: a common author, a common dependency, a common process. Without one it is an association in the listener's head, not a property of the thing. The reverse move — putting a respected name next to it — is just as fallacious.

Claim.

This recipe has a bit too much salt for that volume.

Have you ever cooked for twenty people? Open a restaurant and then we'll talk.

Why it is a fallacy.

Scales and tasting check salt against the weight of the food. Cooking for twenty makes the opinion more likely right, but the grams can be recounted right now.

At work.

At an architecture review: “I've shipped three systems at this scale” instead of an estimate for the new sharding scheme. Experience is a reason to listen carefully, not a substitute for the estimate: requests per shard, the hot key, what happens on resharding.

Achievements speak to the speaker's past success, not to the quality of a given argument. The move works both ways: the author's success is offered as proof they are right, the opponent's lack of it as proof they are wrong. Either way the argument itself goes unexamined. Experience matters when a claim rests on personal testimony. Then you check whether the area of experience matches the question, not the size of the résumé.

Claim.

The course promises a result in a week, and what that result consists of isn't said on the page.

You haven't done a single stage and haven't read the handbook, so you can't judge.

Why it is a fallacy.

The remark is about what is published: the page has no description of the result. If the manual fixes that, showing the paragraph is enough.

At work.

“First read every design doc from the last three years and the scheduler code, then we'll talk about timeouts.” If the answer is in the docs, a link to the section is enough. Demanding to read everything dodges the answer and hides that the docs don't answer the question.

A demand for erudition replaces an answer. An objection either points to a specific defect — a contradiction, missing data, a wrong step — or it doesn't, and that is visible from the objection itself. Pointing to unread material is a condition that can be pushed back forever: there is always one more volume. The honest version names what in the unread material settles the objection and gives a link.

Claim.

This subscription is a bad deal: over a year it costs more than buying separately.

You just grew up in a family that saved on everything, hence the fear of subscriptions.

Why it is a fallacy.

Even if the biography is right, it explains why the conclusion appeals to the person; it doesn't check the arithmetic. The yearly total doesn't depend on anyone's childhood.

At work.

“You're against the orchestrator because you got burned at your last job.” Maybe. But an argument was given: the cost of running a cluster for three services. Until the numbers are examined, diagnosing motives only covers for the missing answer.

The move has two steps and the first is skipped. Instead of “I'll show the claim is false” it is “since it's false, I'll explain what fear or experience it grew from”. A psychological explanation can be built for any belief, true ones included. So it does not tell truth from falsehood and cannot be a refutation. C. S. Lewis coined the term. Unlike the genetic fallacy, the origin here is not an argument against the claim but a stand-in for an argument nobody made.

Claim.

The internet bill has a rental charge for the router we returned, second month running.

The speed went up though — the neighbours don't have that.

Why it is a fallacy.

The speed and the extra line on the bill are independent facts. The refund question is where it was, but now the tariff is up for discussion.

At work.

An incident review asks why the alert was silent for forty minutes. The answer is a story about how fast the rollback was. The rollback really was fast, but it has nothing to do with the gap in monitoring.

The reply neither supports nor refutes the claim — it changes the subject. There may be no lie in it: everything said is true, just about something else. The test: after the reply, can the original question be asked again word for word? If so, it isn't closed.

Claim.

We're discussing who does the dishes in the evenings.

Why do you always leave everything to me?

Why it is a fallacy.

Nobody checked “always” and “everything”. “Because I get home late” confirms them. “That's not true” looks like dodging. Both lose.

At work.

In review: “Why do you keep ignoring our naming conventions?” “Keep” and “ignoring” are already built in, though the dispute is about one method. Surveys suffer the same: “How much has the new release process helped you?” assumes it helped. Neutral: “how has the time from merge to production changed”.

The disputed claim is hidden in the question itself. It asks “why” or “when” before “is it true” is settled. Both “yes” and “no” accept the premise, so the person answering loses before they answer. The premise needs its own support, not a ride inside a question.

Claim.

We agreed: leave requests go in two weeks ahead.

You're seriously going to refuse? My tickets are booked, I've waited for this trip all year.

Why it is a fallacy.

Tickets already bought are a strong reason for an exception now. They say nothing about whether the rule itself is needed. Two different things were discussed and decided as one.

At work.

“Don't reject the PR, they sat on it until three in the morning.” The effort belongs to a conversation about workload, not about whether the code is correct. Via fear: “if we don't buy this scanner, the next leak will bury us.” Instead of probability, damage and how well the control works, there is a picture of disaster.

Emotion in itself is not a fallacy: it signals values and the cost of risk, and no decision is made without it. The fallacy is putting a feeling in place of the missing argument, so that the strength of the feeling becomes the measure of truth. The test: strip the emotion. If no data and no mechanism remain, there was no argument.

Claim.

What was said was: “If the guests don't come, we don't have to cook a hot dish — salads will do.”

You said yourself we don't have to cook.

Why it is a fallacy.

The condition “if the guests don't come” is dropped. A conditional permission became an unconditional statement, though the quote is technically accurate.

At work.

A thread said: “this service can move to its own repository once the contract stabilises.” A month later a ticket links the same thread as “the team agreed to the move”. In a postmortem: “we wrote ourselves that the risk was acceptable” — without the second half, “at current traffic”.

Every word of the quote is genuine; the cut does the distorting. Lost are “possibly”, the condition (“if the load doubles”), a negation, the scale, the date. In effect it is a straw man built from the opponent's real words. It is harder to challenge: an objection gets “I quoted you word for word”.

Claim.

Let's go to your parents just for Saturday this time, not the whole weekend.

So you find my family hard? Then let's settle right now whether we see them at all.

Why it is a fallacy.

The objection was about the length of one trip. The inflated version doesn't follow from it, but it can't be closed in one conversation. And the Saturday question stays unresolved.

At work.

In review, “this query is missing an index” becomes “you don't trust our data model, let's revisit the whole schema”. Half a day goes on it and the index never gets added. The second kind: “some benchmarks say gRPC is faster, others say there's no difference, so it can't be measured.” The spread shows exactly which measurement to run.

A disagreement has limits: subject, extent, conditions. The move erases them in two ways. First, “I disagree with this point” becomes “you're against the whole approach”, and the dispute is with a position nobody held. Second, because experts differ on details, it is concluded that nothing is known about the question. Either way nothing is left to check.

Claim.

If we leave at six on a Friday, we'll sit in traffic for two hours.

Normal people don't build their lives around traffic jams.

Why it is a fallacy.

The reply judges the person estimating travel time, not the estimate. The traffic jam won't clear because of a judgement, and the departure time is still unanswered.

At work.

“Good engineers don't write code without tests” instead of answering whether we meet the deadline with tests for this module. The conversation moves from planning to who is a good engineer. In an incident review: “the on-call engineer was obliged to check the dashboard” is about the norm, not about why the dashboard didn't distinguish degradation from a normal peak.

A moral judgement replaces a claim about facts. “That's not how it's done” answers “what should be done”, not “what happened” or “what will happen”. It mirrors the naturalistic fallacy: there “ought” is derived from “is”, here “is” from “ought”. On top of that, the opponent's objection becomes a misdeed, and they have to defend themselves off the point.

Claim.

Why do we renew the insurance with this agent every year when the one next door is cheaper?

That's how it's done, don't get clever.

Why it is a fallacy.

“That's how it's done” describes a habit, not a reason. The price difference is unexplained, but continuing has become awkward. That is the move doing its job.

At work.

To “why is there a retry with a 50 ms interval here” the answer is “legacy, don't touch it” — and a year later the next person asks again. Typical stoppers: “it's an architectural decision”, “everyone does it”, “the seniors know better”. The test: if the reply fits any question equally well, it answers none.

The phrase looks like a conclusion but has no premise and no data: “that's how it has always been”, “it's obvious”, “the business decided”. It works socially: carrying on feels awkward, like arguing with common knowledge. A cliché can be neither checked nor refuted — it has no content that could turn out false.

Claim.

The water meter seems to be lying: usage has tripled and we live the same way.

Nonsense, meters don't lie.

Why it is a fallacy.

This is the opposite opinion, not an objection. Neither another cause of the increase nor a way to check the readings is named.

At work.

An RFC gets the comment “this is over-engineering” with no word on which requirement is unnecessary or what is cheaper. At grooming, a five-day estimate is met with “that's an hour's work” without going through a single item. The conversation is on topic but has no checkable statement.

The reply is one verdict: “nonsense”, “not serious”, “won't fly”. No premise is challenged, no counterexample is given. The name comes from Samuel Johnson kicking a stone in reply to Berkeley's argument: a demonstration instead of a refutation. It costs the responder nothing, while the author has to guess what exactly is being disputed.

Claim.

You parked in a disabled bay.

Everyone parks like that here, look, two more cars next to it.

Why it is a fallacy.

Two neighbouring cars don't make the space allowed. The repetition shows the problem is widespread, not that there isn't one.

At work.

“Yes, I hard-coded the key, but the next service keeps it in config too.” A second key is a second ticket, not the closing of the first. The same way around a process: “the last release also went out on a Friday without review” turns “roll back or fix” into an argument about past releases.

“Someone else did the same” does not make an act acceptable: both may be violations. In conversation it is a diversion: “what do we do about this” becomes “who else did it”. The other case is relevant to a different question — whether the norm is applied fairly, or what to fix first. Not to whether there was a violation here.

Claim.

In the building the shared bin goes out on a schedule, everyone takes a turn.

Yes, but I have a small child and I work from home, so let the neighbours take my turn.

Why it is a fallacy.

The circumstance is not offered as a criterion for everyone in that situation. It is a reason for one person not to follow the rule. There are no conditions, no time limit, no return to the rota. The exception exists for exactly one person.

At work.

“Every service goes through security review before release” — and right away “ours is experimental, we don't need it”. An exception is legitimate only if the policy sets its limits in advance: which data, which access, which audience, a deadline, an owner and automatic expiry. The same move: “that test is flaky only for us, we'll disable it on our side”.

The rule applies to everyone except the convenient case. The feature that rescues this case is named only after it is clear whom it benefits. It does not follow from any criterion agreed in advance. The test: would this criterion have been written into the rule before anyone knew whose case it rescues? If yes, it is a rule with a scope, not special pleading.

Claim.

This cooking site is a reliable source of recipes.

How do you know? — All the recipes there are correct. — And how do you know they're correct? — Well, the site is reliable.

Why it is a fallacy.

The ground is the same thesis in other words. A check must rest on something outside it: a second source or your own result from the recipe.

At work.

“The model is good because it matches the labels; the labels are good because the model reproduces them confidently.” Without an independent gold set the system confirms itself. The same with alerts: “the alert is configured correctly because there were no false positives” — while it may never fire at all.

The form: A because B; B because A. In short: A because A, where the second A is worded differently. Formally the inference is valid: A does follow from A. That is why it is dangerous — it passes the check on form and gives no independent support. The test: draw arrows “claim ← ground”. If there is a path from the thesis back to the thesis, there is no support.

Claim.

If it's raining, the pavement is wet.

The pavement is wet, so it was raining.

Why it is a fallacy.

Asphalt is wet after a street sweeper and after a burst pipe too. Different causes give the same effect, so the effect does not pick out the cause.

At work.

“If the certificate has expired, the TLS handshake fails. The handshake fails, so the certificate has expired.” It also fails on a cipher suite mismatch, a wrong SNI or a skewed clock on the host.

The form: if A then B; B; therefore A. Formally: A → B, B ⊢ A. The form does not preserve truth. Counterexample: A is false and B is true for another reason — the premises hold, the conclusion does not. The mistake is reading “if” as “only if” and taking a sufficient condition for a necessary one. The valid neighbour is modus ponens: A → B, A ⊢ B.

Claim.

My missing key is in this box.

Don't believe me? Open it and prove it isn't there.

Why it is a fallacy.

The first person made the claim, and checking it costs them one action. Demanding proof of absence makes a bare assertion the default position: true until refuted.

At work.

“My patch breaks nothing, find where it does.” In engineering it is the other way round: the author of a change supports it with a test, a benchmark, a rollback plan. Safety has a legitimate asymmetry: unproven harm does not oblige you to do nothing. But caution does not make the threat proven.

Whoever makes the claim must support it. “Prove it isn't so” swaps a doable task — show one piece of evidence — for an impossible one: go through every possible case. The burden can move: after enough evidence the other side must dispute the data or bring counter-evidence. The mistake is different — the burden is sent where nobody has claimed anything.

Claim.

On Saturday either Anya or Boris will drop by.

Anya's already written that she's coming, so no Boris, we're not putting out a third chair.

Why it is a fallacy.

The sentence did not promise that exactly one would come. Until someone says “one of the two”, Anya coming says nothing about Boris.

At work.

“The incident was caused by a config error or a code error. The config was broken, so the code is clean.” The investigation is closed and the second cause stays in production. In code: `const allowed = isEmployee || hasBetaAccess;` and below `if (isEmployee) assert(!hasBetaAccess);` — the assert fails for an employee with beta access.

The form: A or B; A; therefore not B. Formally: A ∨ B, A ⊢ ¬B. For an ordinary “or” the form does not preserve truth: A and B can both be true. It is valid only for an explicit “exactly one of the two”: A ⊕ B, A ⊢ ¬B. For an ordinary “or” another form is valid: A ∨ B, ¬B ⊢ A.

Claim.

We've got mice in this flat.

Nobody has ever seen a mouse, so there are no mice.

Why it is a fallacy.

Nobody searched: no traps were set, nobody looked behind the stove. “We have not seen any” and “there are none” are different claims. The second needs a search that would have found mice if they were there.

At work.

“There is nothing in the logs, so there was no error.” That path may have no logging, the level may be WARN, the record may have been lost in rotation. A correct conclusion after a check is limited: “a full scan of the image with known signatures found no evidence of these CVEs”, not “the image is safe”.

Two mirror forms: “it is not proven that P, so not P” and “it is not proven that not P, so P”. Both are invalid: ignorance is a state of the knower, not a property of the world. Absence of evidence speaks to absence only under conditions: the search used a suitable method, the method would have found the object, the search area is covered, the result is reproducible. Then the conclusion is stated within those limits.

Claim.

If an item is fragile, a special sticker goes on the box.

There's no sticker, so it isn't fragile, it can go at the bottom.

Why it is a fallacy.

The sticker could have been forgotten or could have peeled off. The rule promised a sticker on fragile items, not sturdiness of everything without one.

At work.

“If the request comes from an administrator, the report is available. It does not, so there is no access.” But an auditor or the resource owner may have the right too. The same in diagnosis: “there was no release, so the degradation is not from a change”. Config, feature flags and data change without a release.

The form: if A then B; not A; therefore not B. Formally: A → B, ¬A ⊢ ¬B. Counterexample: A is false and B is true for another reason — the premises hold, the conclusion does not. The implication forbids one combination: A true and B false. When A is false it says nothing. The valid neighbour is modus tollens: A → B, ¬B ⊢ ¬A.

Claim.

Going over the bridge to the cottage is faster than going round.

Why? — Because it's faster. I've told you twenty times: just faster, that's all.

Why it is a fallacy.

On the fifth repetition there is as much data about travel time as on the first: none. One measurement on two routes settles the question.

At work.

“This library doesn't suit us” in a third email in a row without a single number. “Microservices are faster” at every design review. Repetition is fine only as a pointer to an argument already made: “see the measurement above”. Otherwise the decision goes not to whoever is right but to whoever keeps writing longest.

Repetition adds no facts: after the tenth time there is exactly as much evidence as after the first. The move works on psychology — a familiar phrase seems more plausible — not on logic. It is a relative of circular reasoning. There the thesis props itself up by restatement; here it takes the place of a ground through frequency and volume.

Claim.

The kettle leaks, it's time to fix it.

Come on, it's a great kettle, we bought it five years ago and it still boils water in three minutes.

Why it is a fallacy.

Nobody disputed that the kettle boils water and lasts five years. The claim to refute was “it leaks”; what got refuted was “it is bad” — a claim nobody made.

At work.

“This stream needs idempotency” — “Kafka is a complex technology.” The answer may be true and miss the requirement. In an incident review: to “the alert fired forty minutes late” the reply is “but we fixed it in two hours”. The metric is real, the claim is different, and the gap in detection remains.

A real refutation contradicts the same claim about the same subject. A false one proves something nearby: a weaker claim, another topic, a special case — and passes the win off as a refutation of the original. The form of the inference may be flawless. The error is in the address: the conclusion is true but irrelevant to the dispute.

Claim.

This milk is pasteurised, there's no need to boil it before making porridge.

I don't know, I think any milk should be boiled. I'm entitled to my opinion.

Why it is a fallacy.

Nobody disputed the right. The question was a fact — what pasteurisation does. Appealing to the right does not answer it, though one line on the package settles it.

At work.

In code review: “I think we should split the layers” — “I think we shouldn't, it's a matter of taste.” Some decisions really are taste; those are settled by a linter or a coin. But “I just think so” instead of an argument about coupling or the cost of future changes is a refusal to justify.

Two things get mixed up: the freedom to hold a position — nobody disputes it — and whether the position is justified, which is what is being discussed. “That's my opinion” adds no evidence and ends the conversation. A dispute about facts becomes a dispute about rights, where any objection looks like an attack. In effect it refuses the burden of proof: “my opinion” instead of “here is why”.

Claim.

I throw out any expired food the same day.

I checked the fridge — nothing expired. So the rule works and is followed perfectly.

Why it is a fallacy.

The rule has never been applied: there was not a single case it covers. “Never violated” does not mean “confirmed”. On an empty set “I eat everything that has expired” is just as true.

At work.

A test whose filter dropped every record passes green: the invariant “for all records” is true on an empty sample. An alert “no SLA violations in 24 hours” behaves the same if the metric stopped arriving. The cure is a count check: first assert how many objects meet the condition, then assert the property.

In classical logic A → B is true when A is false. So ∀x(Sx → Px) is true if no x satisfies S. “All unicorns in my building are polite” is true. There is no formal error; the rule is correct. The trap is in reading: a vacuous truth is taken for confirmation by experience. But ∃x(Sx ∧ Px) does not follow from ∀x(Sx → Px). The sign: with an empty S the opposite rule ∀x(Sx → ¬Px) is true as well.

Claim.

On a slope like that you put the car on the handbrake.

You said “everyone does it” — that's an appeal to the majority, a classic fallacy. So no handbrake needed.

Why it is a fallacy.

The argument really was weak, but the slope is still there. The right outcome is “this ground doesn't work, give another one”, not “the claim is false”.

At work.

At a design review: “your latency argument is post hoc, so we don't need the index.” The reasoning error is real, but the need for the index has not gone away — it is just not proven. A query plan checks it. The same in incident reviews: calling someone's hypothesis confirmation bias and closing it without checking the data.

The form: argument A supports C; A contains a fallacy; therefore not C. The form does not preserve truth: a true claim can have bad arguments. Finding a fallacy returns the claim to “not proven”, not “refuted”. For someone who has learned the catalogue this is the most dangerous trap. The list of names becomes a weapon: instead of checking the claim, people hunt for labels, and talk about the matter turns into talk about how the opponent argues badly.

Claim.

The courier service is bad.

They brought my order late twice, so they are always late.

Why it is a fallacy.

Two cases from one person don't give a share of late deliveries. And failures stick in memory better than a dozen on-time deliveries.

At work.

Two crashes on one instance become “the library leaks”, one benchmark run on a laptop becomes “the new version is faster”. The cure is the number of observations and the spread next to the conclusion: p95 over 40,000 production requests in a week, not “it opens fast for me”.

Induction is legitimate, but its strength depends on the sample size, how cases were selected and the spread within the class. The fallacy is when the number of observations isn't stated, the cases are whatever was at hand, and the conclusion has no “how many” and no caveats. The question is not “few or many examples” but “does the sample reflect the class or only what I noticed”. The legitimate version names its base: how many observations, where from, and how uncertain the conclusion is.

Claim.

A child asks to go to bed half an hour later on Friday.

Allow it once and he will stop going to bed on time at all.

Why it is a fallacy.

Every step between “later on Friday” and “never on time” is missing. Nor is it said why the rule “weekdays as usual” would stop working.

At work.

“Turn on one feature flag with no expiry and the product becomes a pile of branches.” Sometimes true: flags without an owner and an expiry date really do pile up, and a counter shows it. The honest argument shows the counter and the missing clean-up, not just the scary ending.

The fallacy is not naming a chain of consequences but skipping its links: the mechanism of each step, its probability, the timing and what could stop the chain. The legitimate version is common. If the mechanism is named and confirmed — feedback, accumulating precedents, no stopping rule — the argument becomes a risk estimate. That can be disputed with numbers.

Claim.

We need to decide what to do with the old car.

Either we sell it now or we drive it for another five years.

Why it is a fallacy.

There is repair and sale in a year, a trade-in, driving until the first big breakdown. The two items were picked, not derived from constraints.

At work.

“Either we rewrite from scratch or we live with this code”, “either 100% coverage or no tests”. There is nearly always a gradual migration, extracting one module, covering the critical path. The check is cheap: name a third option out loud and see whether it is rejected with an argument or with silence.

A split “P or not P” is exhaustive by construction. A list “A or B” of two concrete solutions almost never is. The fallacy is when mixed options, postponing and “change nothing for now” drop out of the list. The legitimate version: the options really are exhaustive when there is a hard constraint or the resource is already spent. Then the dilemma is real, and the answer is a choice.

Claim.

The guests praised every dish individually.

So the dinner as a whole was a success.

Why it is a fallacy.

The dishes may not go together: three similar flavours in a row, everything cold by the time it is served. “Tasty” doesn't add up by itself.

At work.

“Each service handles 1000 RPS, so the chain handles 1000 RPS.” The chain handles as much as its narrowest link, and less with fan-out. The rule: name how the property combines. Latency of a chain adds up, availability multiplies, memory is shared.

Going from part to whole is legitimate for properties that add up, or when the rule of combination is proven: the mass of the whole is the sum of the masses of the parts. Otherwise the combination has behaviour of its own: a bottleneck, interaction, contention for a shared resource, ordering. The fallacy is silently assuming the whole behaves like its parts. The honest move is to name how the property combines and check it at the edges.

Claim.

The team closes tasks quickly.

So everyone on the team works quickly.

Why it is a fallacy.

A team's speed comes from how work is shared and how people help each other. One person's pace can't be derived from it.

At work.

“The system is 99.9% available, so every component is 99.9% available.” Components have different SLOs and redundancy; some can be down with no effect. “Average latency is 50 ms, so requests take 50 ms”: the p99 tail has a life of its own.

The reverse of composition: “the system has X”, so “every component has X”. It is legitimate when the property is built into the set: every element has the feature the set was gathered by. For aggregates — averages, sums, reliability — it fails: they rest on compensation and redundancy. A special case is the ecological fallacy, where group statistics are applied to one person.

Claim.

A true hiker never takes a wheeled suitcase.

— Marina spent three weeks in the mountains with a suitcase. — Then she is not a true hiker.

Why it is a fallacy.

The claim has been made irrefutable: any counterexample now drops out of the class on its own. The statement no longer says anything about the world.

At work.

“True microservices don't turn into a distributed monolith”, and a system that did is declared not true microservices. The style becomes unbeatable: no possible bad outcome is left for it.

The generalisation “all A are B” meets an A that isn't B. Instead of weakening the generalisation, the speaker changes the definition of A so the awkward case falls outside it. One question: was the criterion set before the counterexample or after? The legitimate version: a definition may exclude an object if it was written down in advance and applied equally to one's own and others' examples.

Claim.

How much salt to put in the soup.

— A spoonful. — Three. — Two, then: the truth is always in the middle.

Why it is a fallacy.

The right amount of salt depends on the pot and taste, not on the average of two opinions. Had the second person said “ten”, the “truth” would have moved to five.

At work.

“One estimated the move at a month, the other at a year — so six months.” The deadline comes from breaking down the work and data on similar tasks, not from the midpoint of estimates. Splitting a CPU quota between teams is a legitimate compromise: there the middle is a decision, not a fact.

The midpoint between two claims is a fact about where the claims stand, not about the world. The middle position can be false and an extreme one true. And the “truth” is easy to move by taking a more radical pole. The legitimate version: when dividing a resource or negotiating, a compromise is a normal solution. In a question of measurement, an in-between estimate is right if it comes from data, not from the symmetry of opinions.

Claim.

One hair does not make a person bald.

So there are no bald people at all — the boundary does not fall anywhere, after all.

Why it is a fallacy.

A gradual transition means there are borderline cases, not that the extremes are indistinguishable.

At work.

“Nobody can name the request after which overload began, so there is no overload.” What works is a threshold, an interval and a check of how much the decision depends on the threshold. The flip side: “79 ms is fast, 80 ms is slow”, though the 80 ms SLO was made up in a meeting. Such a threshold gets revised, not defended as a law of nature.

There is no breaking point between “cold” and “hot”. But a fuzzy boundary cancels not the difference, only the hope of a single natural threshold. In practice you pick a working threshold, say honestly that it was chosen rather than found, and give the uncertainty around it. The reverse fallacy is just as common: a chosen threshold is taken for a natural break.

Claim.

A flat renovation should be run to a plan.

A flat is like an organism, and an organism is treated as a whole; so the renovation has to be done in all the rooms at once.

Why it is a fallacy.

What a flat and a body share is an image of wholeness, not what decides the order of work. Rooms have no shared bloodstream, and you can live in half the flat.

At work.

“A database is like a file system, so backing up by copying files will do.” They share a lot, but a database has open transactions and write ordering. Taking an analogy apart is finite: list the similarities, the differences and which of them the conclusion depends on.

Analogy is a legitimate and sometimes the only tool: it carries a conclusion from a studied case to a new one. Its strength depends on whether the shared feature is responsible for the conclusion and whether differences work against it. The fallacy is carrying over an irrelevant feature, leaving differences unnamed, and resting the similarity on an image. The test: name the feature being carried over and explain why it is the one responsible for the property in question.

Claim.

Both neighbours are loud.

Drilling a wall once a year in the daytime is the same thing as playing music every night. They both make noise, after all.

Why it is a fallacy.

The shared category “noise” exists, but frequency, timing and reversibility differ by orders of magnitude. The equality rests on a word, not a measurement.

At work.

“Both teams broke the process”: one shipped a hotfix without review during an incident, the other has merged without tests for six months. “Both options have risks” is true and useless until probability and damage are named.

A shared property can always be found: being five minutes late and a cancelled trip are both “breaking an agreement”. The fallacy is letting the shared name replace measurement: scale, frequency, reversibility, cost. A related form is false balance: two positions get equal space only because there are two. A legitimate comparison names the axis on which the cases really are equal and admits they differ on others.

Claim.

Whether to fit a second lock on the door.

Any lock can be picked, so there is no point.

Why it is a fallacy.

The question is not a guarantee but how much the probability and losses change compared with one lock, and what it costs.

At work.

“Canary releases don't catch every incident, so they're useless”, “a second factor won't stop a targeted attack, so we won't roll it out”. Each measure removes its own class of failures. It is judged by the share of incidents removed and its cost, not by the fact that some remain.

The comparison should be not with imaginary perfection but with what happens without the measure and with the best available option. An honest comparison has three numbers: damage without the measure, damage with it, and the cost of the measure including side effects. The reverse fallacy is accepting any improvement without comparing it to the best alternative. The same substitution, in the other direction.

Claim.

A neighbour took a vitamin at the first sign of a cold and was better in three days.

So the vitamin cures colds.

Why it is a fallacy.

A cold passes in a few days without treatment, and the vitamin is taken at the peak of symptoms. Cases of “took it and was ill for a week” don't come up in conversation. There is no comparison group and no number of tries.

At work.

“At my last job Kafka lost messages, so we won't use it” — one incident three years ago, on someone else's version and config. In support, three loud tickets in a morning look like an epidemic until you compute the share: 3 reports in 40,000 sessions is normal background. One vivid case sets a hypothesis; decisions are made on frequency.

Personal experience is a sample of one, chosen because it stuck in memory. Other explanations are almost always at hand. Coincidence. Regression to the mean: people seek help at the worst moment, and after it things usually improve on their own. Survivorship bias: cases where it didn't work just aren't told. Experience is fine as a source of a hypothesis but not as an estimate of frequency: it has no denominator.

Claim.

Four children were born in the house on the corner last year, and all of them were boys.

Something in that house affects the sex of the child: the water, the layout, the location.

Why it is a fallacy.

The building was chosen after the coincidence was noticed. Four boys in a row is about one chance in sixteen, and a city with thousands of buildings must have dozens of such runs.

At work.

An A/B test shows no effect on the whole sample. The analyst slices the data and finds +8% conversion for Android in Germany in week two. There were about a hundred tests; five false findings are expected with no effect at all. The right move: record the finding as a hypothesis and check it with a pre-registered test on new traffic.

Any large dataset has clusters — a property of randomness, not a signal. The fallacy is choosing the segment, window or metric after seeing the result and presenting the finding as a confirmed prediction. The explanation is the arithmetic of multiple comparisons. Twenty metrics across five segments in four windows is hundreds of tests, and at the 0.05 level dozens of “significant” results appear by themselves. A hypothesis found in the data is tested only on new data.

Claim.

The more ice cream a city sells in a day, the more lifeguard callouts there are at the beach.

Ice cream makes people careless in the water.

Why it is a fallacy.

The common cause is heat: it sends people both to the kiosk and into the water. Neither quantity affects the other. Remove the ice cream and the calls won't drop.

At work.

A dashboard shows that services with frequent deploys have more incidents. “Frequent releases break production” turns the picture upside down. Important, active services get more changes, more traffic and better monitoring — and so more noticed incidents. Look at the change failure rate, not incidents per service.

Changing together fits at least six pictures. X causes Y. Y causes X. A common cause Z drives both. The link is created by selection — by how the data got into the sample. A feedback loop. Plain coincidence. Correlation narrows the list of hypotheses but doesn't choose among them. To speak of a cause you need a mechanism, an order in time and a comparison group.

Claim.

The cinema tickets are bought, but by the tenth minute it is clear the film is dull.

We have to sit it out to the end, otherwise the money is wasted.

Why it is a fallacy.

The money is spent either way. The choice is between “an hour and a half of boredom” and “a free evening”, and the past payment isn't part of it.

At work.

Six engineers have spent two years on an internal platform, and service migration hasn't moved. “We've invested too much to stop” replaces the real question: if the platform didn't exist today, would we start it at the current price of an off-the-shelf solution? The cure is process: stop conditions and a budget are written down before the start, and the decision to continue is not made by the idea's author.

Money, time and reputation already spent won't come back whatever you choose. They are the same in both options, so they can't help you choose. Compare future benefit, future cost and the best alternative. The past matters only where it created an asset, an obligation, knowledge or an exit cost. Next to it stands escalation of commitment: after a public decision it is easier to invest more than to admit a mistake.

Claim.

The child coughed for a week; yesterday he was given a syrup a neighbour suggested — today the cough is nearly gone.

The syrup cured the cough.

Why it is a fallacy.

The syrup was given on day seven, when the illness was already fading. Treatment almost always starts at the worst point, and after it things improve on average with or without treatment.

At work.

A release went out at 14:05, p99 tripled at 14:12, it was rolled back and got better; the incident closes with cause “the release”. Check: did the graph start rising before 14:05? Did a batch job start, did a dependency degrade? A rollback changes the whole system state, so “it got better after the rollback” is post hoc as well. A cause is confirmed by a mechanism and a reproduction, not by matching timestamps.

Order in time is necessary for a cause but not sufficient. Other explanations: coincidence; a common cause of both events; a process that started earlier and showed up later; regression to the mean — people intervene at the peak of a problem, and after the peak things improve on their own; the measurement changed, not the thing measured. The closer the events in time, the stronger the illusion and the more a comparison group is needed.

Claim.

The average income in district A is higher than in district B.

So the person you know from district A earns more than the one from district B.

Why it is a fallacy.

The average says nothing about a pair of specific people. District A may have a few very rich households and many modest ones. The spread within districts is larger than the difference between the averages.

At work.

Teams with high test coverage break production less often. From this people conclude that every engineer who raises coverage in their module will reduce their incidents. But at team level what works is review, CI, on-call and which services the team got. Likewise, 99.9% availability of a service doesn't mean 99.9% for every client. Name the unit of analysis before counting.

Group statistics and individual statistics are different quantities. The relationship between them can differ in strength and even in sign. A group-level link is usually explained by group composition and subgroup weights, not by how people behave. The extreme case is Simpson's paradox: the trend in every group is the opposite of the trend in the total. The mirror fallacy is the atomistic one: an individual pattern is applied to a group.

Claim.

Last summer a family picked a hotel from the reviews and the photos; on arrival there was a building site under the windows.

How could you not check — you should simply have picked a different hotel.

Why it is a fallacy.

The construction started after the reviews were published, and no source showed it then. The outcome is being judged, not the decision: with that information the choice was reasonable.

At work.

In a postmortem: “the alert fired at 3:40, why didn't the on-call engineer react?” At 3:40 that alert was one of seventeen, fourteen of which fire every night. An honest review reconstructs what was visible and changes the system: adds a signal, a runbook or automation. The historian's fallacy looks for who failed to guess, and teaches people to write less in reports.

The outcome is known, and the signals that led to it look obvious in hindsight. The dozens of similar signals drowning in the noise back then are invisible. The explanation is often not “they didn't think” but “the signal didn't stand out from the background then”. Behind it is the “I knew it all along” bias. An honest assessment asks what was known at the moment of decision, not why nobody guessed what we know now.

Claim.

On a yoghurt pot: “New formula — 50% less sugar”.

So the product is low in sugar and suits people watching what they eat.

Why it is a fallacy.

It doesn't say less than what. Perhaps than the previous version, which had twice the usual sugar. Half of a lot is still a lot. Without the starting level and grams per serving the comparison can't be checked.

At work.

“The new service is three times faster” — than what: the old version on a cold cache, on another machine, under another load? Mean or p99? A report classic: “errors up 50%” with no request count — while with doubled traffic the error rate actually fell. Ask for the numerator, denominator, baseline, window and absolute values with spread.

“Faster”, “cheaper”, “40% more efficient” compare two things. Until it is said with what, under what conditions and by which metric, they can't be checked. The listener fills in the version most favourable to the speaker. The catches hide in what is left out: a convenient baseline, an unnamed denominator, a relative effect instead of an absolute one, a chosen window.

Claim.

In the lottery the number 17 has not come up for five draws in a row.

So 17 has a better chance now — it is already “due”.

Why it is a fallacy.

The ball doesn't remember past draws; the probability is the same. There is no force that evens out frequencies over a short run.

At work.

“Four quiet on-call nights — tonight it's bound to blow up” and the reverse “ten green builds in a row, we can drop the checks”. Both take independence on faith. More useful: if a flaky test failed 4 times in 100 and failed three times in an hour today, that is nearly impossible under independence. So the trials are dependent — look for a shared resource or an exhausted connection pool.

If trials are independent and the probability is constant, past outcomes don't change the next one: a coin has no memory. Frequencies even out not by paying back a debt but because the streak drowns in a mass of new trials. The mirror extreme is the “hot hand”, where a streak is taken as a pattern. Both silently assume a model of the process. So what needs checking is not the length of the streak but independence itself: a real process can depend on its past, wear out or share a resource.

Claim.

An acquaintance recommends an online course and sends over five glowing reviews.

The reviews are excellent, so the course works.

Why it is a fallacy.

Five reviews were picked from hundreds, by an interested person. Neither the drop-out rate nor the negative reviews are shown.

At work.

A release report: conversion +12% over nine chosen days. Off-screen: the window starts right after a disastrous Monday, a discount mailing fell into it, and two of twenty metrics are shown. The defence is procedure: the primary metric, window and stopping rule are written down before the experiment, and negative results are published on a par with positive ones.

Observations are selected for agreeing with the claim, so the conclusion is set by the procedure, not the data. The explanation is always the same and always off-screen: the observations not chosen. Special forms are a convenient time window, showing only surviving cases, and tweaking the analysis until the desired result appears. It differs from honest selection in that the criterion was made up after seeing the data and isn't disclosed.

Claim.

Two people struck up a conversation by chance in a queue, and a year later they married.

They were meant to meet, everything was leading up to it.

Why it is a fallacy.

Inevitability is assigned after the fact: the thousands of queues where nothing happened don't make it into the story. That the event happened doesn't mean it was likely.

At work.

After an incident: “this architecture was bound to fail sooner or later.” Maybe. But the same logic explains just as smoothly the three years it didn't fail. The antidote is writing down forecasts with probabilities in advance: a decision log and a premortem before launch. After the incident, compare with the records.

The outcome that happened seems the only possible one, because the other branches are no longer visible. We see one path and build a coherent story onto it. Two mechanisms work here: “I knew it all along”, which rewrites the memory of earlier expectations, and the pull to explain an outcome by a chain of steps that “led” to it. The check is what estimates were given before the event, not how smooth the story sounds after.

Claim.

The dinner burned, the guests left early, the evening was a failure.

It is all the oven — it runs too hot.

Why it is a fallacy.

Several things came together: a new recipe, timing meant for a different portion, no timer set, guests invited on a weekday. The oven may be part of the explanation, but it doesn't produce this outcome alone.

At work.

“The cause of the incident was a heavy SQL query.” Next to it there are usually four more conditions: an index that didn't ship with the migration, retries without backoff, a connection pool of 20, an alert threshold above the real SLO. The incident happened because all five coincided. That is why a postmortem lists contributing factors, not a single root cause.

Complex outcomes usually come from a coincidence of conditions, each insufficient on its own. Naming one factor doesn't rule out the rest and, worse, ends the search. Other explanations here are not alternatives but additions. A special kind is reducing a multi-factor result to a culprit. Then the conversation moves from the mechanism to a person and ends before it has begun.

Claim.

The stain on the bathroom ceiling is most likely from a leak upstairs.

My dentist said stains like that are always from condensation.

Why it is a fallacy.

A dentist knows teeth. On moisture in the ceiling their word is a private opinion, and it pushed aside the simplest step: go upstairs and look. A roofer's word would be testimony, but even that wouldn't replace an inspection.

At work.

“The chief architect said so” closes a question about response time that a twenty-minute measurement settles. A special kind is the anonymous authority: “it's best practice”, “a big company has been through this” — no name, no scale, no conditions. Where a metric exists, citing a person is weaker than a number.

The fallacy starts not with citing an expert but where the citation takes the place of an argument. Three typical forms. The authority speaks outside their field. Their opinion is offered as proof rather than testimony. The source is unnamed — “scientists have proven” — and can't be checked. The legitimate case: a specialist speaks within their field, colleagues don't seriously dispute it, and primary data is unavailable. Then “X thinks so” is a reason to believe with a caveat, but not a ban on checking.

Claim.

The pie dough needs baking powder.

No chemicals, better to use a starter — that is natural.

Why it is a fallacy.

“Natural” is put in place of an answer to the real question: taste, time and how reliably the dough rises. Baking soda and sourdough differ in chemistry and timing, not in naturalness. That is what to argue about.

At work.

“Manual deployment is more honest — a real person is watching.” A manual step isn't safer than an automated one for being natural. Compare error rates and recovery time. “This framework makes you write unnatural code”: until it says what gets worse — readability, coupling, cost of change — “unnatural” means “unfamiliar to me”.

In a dispute “natural” means several incompatible things at once: arising without human intervention, familiar, harmless, eco-friendly. The argument rests not on one meaning but on the word's positive colouring. A thing's value doesn't follow from its origin: hemlock is natural, antibiotics and encryption are not. The reverse form — “artificial, so harmful” — is the same substitution with the opposite sign.

Claim.

The teenager next door built himself a computer out of parts.

Come off it. At his age I could not plug in a mouse. Someone must have built it for him.

Why it is a fallacy.

One's own biography is declared the measure of what is possible. One question checks it: ask him to show how he matched the motherboard to the processor.

At work.

“I don't believe this query runs in 8 ms, that's impossible” — and an argument instead of a profiler and a query plan. In review: “I don't understand how this works, so it's wrong.” Unclear code is a real remark, but then it reads “unreadable, rewrite it”, not “incorrect”.

The premise is about the speaker's imagination, the conclusion about how the world works, and there is no bridge between them. Difficulty imagining a mechanism says something about the arguer's knowledge, not the phenomenon. The reverse form — “there's no other way to explain it, so my version is right”: a lack of imagination is passed off as proof of a single option.

Claim.

In the reading room you may not talk or eat.

Freedom is when there are no prohibitions. A library has prohibitions. So a library deprives people of freedom.

Why it is a fallacy.

In the first sentence “freedom” is the absence of restrictions; in the second it is the freedom to read in quiet. The rules limit the first for the sake of the second. One word hid that these are different things.

At work.

The word “done”. At stand-up it means “the code is written”, in a promise to the customer “it works for users”. The tracker status follows the first meaning, the deadline the second. The same with “stable” (doesn't crash / doesn't change the contract) and “coverage” (lines executed / behaviour checked).

The word quietly changes meaning between the premises: broad in the first, narrow in the second, and the link rests only on the same spelling. Risky words have an everyday and a technical sense: “free”, “open”, “average”, “safe”. The cure is to tag the meanings: freedom₁ is the absence of any restrictions, freedom₂ is the ability to choose. Then the step disappears along with the conclusion.

Claim.

Maybe this year we do the holiday at our place instead of driving halfway across the country?

We have gone to grandmother's for thirty years. It is a tradition.

Why it is a fallacy.

Thirty years is evidence that it suited everyone. But the duration is offered in place of a reason, and conditions have changed: two children now, a day on the road. A real answer would be “it matters to grandma that everyone comes”, and that can be discussed.

At work.

“Don't touch this script, it's been working since 2016.” Not an empty argument: the script has been through hundreds of releases. It becomes empty when it stops anyone asking what the script does and why it fails once a quarter. The reverse trap is removing an unclear step from the pipeline without finding out which incident created it.

A practice's age says it has survived for some time. It doesn't say it is the best or that conditions haven't changed. The fallacy is letting the age close the question “why this way”. There is a legitimate case too. A practice that has long worked under the same conditions without noticeable failures is weak but real evidence. Chesterton's fence belongs here: before removing a rule, find out why it was put there. The difference is whether age serves as data about how it works or as a ban on discussion.

Claim.

I will change your wheel for you in ten minutes.

— Done, there you go. — You changed the wheel all right, but you did not balance it, so you cannot actually fix a car.

Why it is a fallacy.

The promise was about a wheel and ten minutes, and suddenly the check is “can you fix cars at all”. The second question is legitimate but new. It should have been asked before, not after.

At work.

“Show me a benchmark” → shown → “but that's not production” → canary shown → “we need a year of observation”. Another form swaps the metric: p99 was agreed, the report shows the mean. The cure is a decision rule written before the experiment: which number, on what data and over what period counts as enough.

What gets swapped is not a word's meaning but the whole subject: the agreement was “ready by Friday”, the check is “what about quality?”. The new requirement may be reasonable. The fallacy is that the old one was declared sufficient and then withdrawn after the fact, with no explanation of what changed. Unlike an honest clarification, there is no result the arguer would agree to count.

Claim.

The flat renovation took three months instead of one.

A good tradesman is one who finishes on time. So he is no tradesman, and there is nothing to discuss.

Why it is a fallacy.

The definition is built so that the question of why the work was late can't even come up. There could have been many reasons: a late delivery, hidden wiring, a brief that changed three times. A neutral “the work took 90 days against a plan of 30” leaves room for checking.

At work.

“A senior is someone who doesn't ask questions.” “A bug is whatever is filed in the tracker.” The last one is especially persistent: with that definition the goal “zero bugs” is reached without touching the code — just don't file tickets.

The definition stops describing and starts asserting: “micromanagement is the necessary control of irresponsible employees”. Whoever accepts this wording has already accepted the judgement and the cause. A related form is a definition cut so that counterexamples fall outside it. The sign: the disputed claim follows from the definition without a single observation. A neutral definition describes what can be observed and leaves the judgement to a separate discussion.

Claim.

Let us have a romantic dinner with candles.

“Romantic”, strictly speaking, comes from Rome, from the Romance languages. What have candles got to do with it?

Why it is a fallacy.

The word went from “written in the vernacular” to “about love and feeling”. Usage sets today's meaning, not the root. Both people understood perfectly well what dinner was meant.

At work.

“A microservice must be micro — yours is four thousand lines, that's not a microservice.” The prefix became the criterion instead of the ownership boundary and independent deployment. The same argument about serverless: “but there are servers!” Instead of the practice, people discuss whether it is named correctly.

A word's meaning is set by how it is used now, not by what it grew from. “Data” comes from “given”, but how objective data is depends on how it was collected, not on the root. Etymology is useful as the history of a concept but doesn't establish properties of the thing. The reverse form: “the word originally meant something else, so you're using it wrong.” Language changes, and that is not the speakers' mistake.

Claim.

I want to put a wardrobe sixty centimetres deep in the hallway.

The design of the flat does not allow it.

Why it is a fallacy.

It isn't “the design” that forbids it but the width of the hallway, the door, or someone's plan. Until it is said what is in the way, there is nothing to object to. If taste is in the way, that is an argument too, but one that can be discussed.

At work.

“The architecture requires a separate service” — the person who made the decision requires it, or a constraint that can be named. A metric that became a target: velocity was invented to describe pace, but once the team is judged by it, estimates grow, not output.

A name invented for convenience becomes an actor: “the market demands”, “the process decided”, “the architecture doesn't allow”. Someone specific always does the demanding — a person, a document or a nameable constraint. The abstraction removes from the conversation the one you could argue with. The second form makes a metric an entity of its own: “let's raise engagement”, though engagement is a formula over logs. The test: replace the abstraction with a mechanism and see whether the statement still makes sense.

Claim.

It looks like a pipe is leaking behind the bath — the neighbours below have a stain on their ceiling.

Impossible. Otherwise we would have to take up the tiling, and we spent a month laying it.

Why it is a fallacy.

The cost of repairs says nothing about the pipe: it either leaks or it doesn't. The tiles are worth discussing when deciding whether to fix it now or after the holiday. Not when finding out whether there is a leak.

At work.

“If we call this defect a blocker, the release slips, so it's not a blocker.” Severity is set by the harm to users; the release date is a separate decision that can be made knowingly. The reverse form: “this scheme gives us ten times the headroom, so it's right” — the desired result instead of an estimate of cost and risk.

Whether a claim is true and whether its consequences are welcome are different questions, and the argument glues them together: “if this is true, everything has to be redone, so it isn't true.” The only thing at work is not wanting to redo it. A legitimate and quite different thing is an argument about a decision: consequences should affect what to do, not what is. The test: is the dispute about a fact or about a choice of action?

Claim.

We need a kettle to replace the burnt-out one.

Get the one with the touch panel, it is the latest model.

Why it is a fallacy.

The year of release says nothing about heating speed or how long a touch sensor lasts in a humid kitchen. A real argument would be: “newer models have a different heating element, less scale builds up.” That can be checked.

At work.

“We're moving to a new build system, the old one is from 2015.” Age alone is not a defect: the old tool has known workarounds and found bugs. Compare on named points — build time, reproducibility, migration cost — and allow for the new one's bugs simply not having been found yet.

A release date is not the property you pay for. A new solution may remove an old limitation, or it may simply not have had time to collect known problems. It has less operating experience, and newness means uncertainty more than advantage. The argument gains substance when it names what exactly changed and at what cost.

Claim.

By grandmother's recipe the dough has to stand for an hour in a warm place.

That is last century, now it is all done with a food processor in five minutes.

Why it is a fallacy.

The hour is for the yeast, not for tradition. A mixer speeds up kneading, not fermentation. The recipe can be refuted by the properties of yeast and temperature, not by its age.

At work.

“Relational databases are an outdated approach”, “server-side sessions? that's pre-SPA”. A solution's age is not an argument. The argument is which constraint went away: memory got cheaper, replication appeared, the load changed. And old texts on system reliability haven't aged: they describe properties that don't follow fashion.

The judgement moves from content to date: “that's how people thought in the nineties”, “a last-century approach”. The era is passed off as a judge, though observations do the judging. It differs from the appeal to novelty in direction: there the new is praised, here the old is disparaged. Both rely on a date instead of analysis. The argument gains substance when it names which observation or constraint has changed since.