Question bank — KISS — Keep It Simple

False — line-count measures characters, not understanding-time. A branch-free one-liner like (a>b)*a+(a<=b)*b is fewer lines yet harder to reason about, so it violates KISS.

False — KISS bans premature abstraction, not abstraction itself. A pattern that removes real, proven duplication is simplifying; a pattern added for an imagined future is the thing KISS warns against.

False — "Stupid" describes the target audience of the code: it must stay understandable to someone tired, new, or under pressure (future-you at 2 a.m.), not to an insulted author.

False — handling edge cases you don't actually have is over-engineering; each imagined case adds moving parts $n$ and interactions $\left(\genfrac{}{}{0ex}{}{n}{2}\right)$ with zero present benefit.

False — that is over-simplification, a bug. Einstein's razor is "as simple as possible, but no simpler"; dropping needed behaviour breaks correctness, not complexity.

False — cognitive load scales like pairs $C=\frac{n(n-1)}{2}$, which is quadratic, so doubling $n$ roughly quadruples the effort (e.g. $n=3\to 3$ vs $n=6\to 15$, a 5× jump).

False — you write code once but read it many times; clever code optimizes for the single writing moment and pays a tax across every later reading, debugging, and onboarding moment.

False — YAGNI ("You Aren't Gonna Need It") is a tool for achieving KISS: by refusing speculative features you keep $n$ small and the design simple.

False — each small unit has tiny $n$, and $\left(\genfrac{}{}{0ex}{}{n}{2}\right)$ grows super-linearly, so several small functions have far fewer total interactions than one giant one.

Flexibility and simplicity are different axes. Flexibility you don't currently use is speculative generality — it adds moving parts and reading cost now for a benefit that may never arrive.

Compression raised cognitive density (more reasoning per character) even though it lowered line-count. KISS optimizes understanding-time, so this often makes the code less simple.

There is exactly one greeting type today. Abstraction with a single implementation adds $n$ with no benefit; the pattern should arrive when a real second case does, not before.

Short conditions don't reduce the load of holding three open branches simultaneously. Guard clauses / early returns let the reader dispose of each condition and exit, cutting the interactions tracked at once.

Deletion is an engineering win under KISS: an unused param is a moving piece a reader must consider and rule out. Removing it shrinks $n$ and removes questions.

DRY targets proven duplication, not a single occurrence. Abstracting on the first instance is prediction, and premature abstraction is exactly what KISS forbids.

Adding produces visible artifacts (new lines, new features) that look like output, while deletion looks like "nothing" — KISS retrains you to count restraint and removal as real progress.

Because understanding requires tracking how pieces interact, and each of $n$ pieces can pair with the other $n-1$; the unordered pairs are $\frac{n(n-1)}{2}$, so interactions — not raw count — drive difficulty.

Designing for a tired/new reader forces clarity that also helps experts under pressure. Since 90% of a program's life is reading and maintaining, clarity compounds for all readers.

Because $C=\left(\genfrac{}{}{0ex}{}{n}{2}\right)$ is quadratic in $n$: shaving even a few pieces removes a disproportionately large number of interactions, so small simplifications yield large mental savings.

The boring solution matches most readers' mental model and control flow, minimizing understanding-time; cleverness only pays if it removes real complexity, not if it merely looks impressive.

A clear name removes the need for an explanatory comment and lets the reader grasp intent without tracing the code — it lowers reasoning cost, which is what "simple" measures.

Yes, when the problem genuinely doesn't require action (e.g. a no-op default), but only if it still actually solves the problem — "simplest that solves it, and no simpler."

No — splitting a trivial, clear unit adds indirection (extra $n$ across call boundaries) without lowering load. KISS applies to the split too: don't decompose past the point of clarity.

No — that's proven duplication, so abstracting via DRY removes real complexity. KISS only forbade the premature version; the second real case is the trigger. :::

Yes — identical behaviour makes reading cost the tiebreaker, and the readable version wins on understanding-time even though it may have more lines.

Not necessarily — metrics are proxies. High branching that maps cleanly to real, irreducible cases can be simple; KISS targets unnecessary complexity, so judge by understanding-time, not the number alone.

Only with measured evidence — otherwise it's premature optimization, which adds complexity for a speed gain you haven't proven you need. KISS defaults to the simple version until profiling justifies otherwise.

No — that complexity is essential, driven by the problem, not invented by the coder. KISS removes accidental complexity; it never asks you to under-handle genuinely distinct cases.

The clear verbose one, because readability and understanding-time dominate a program's life; the compressed version trades one-time writing satisfaction for repeated reading pain.