KISS — Keep It Simple: Visual walkthrough — Coding deep dive

Before we begin, one promise: every symbol below is earned. We will use exactly two:

$n$ — a plain counting number: how many moving parts a chunk of code has.
$C$ — another number: how many connections between those parts a reader must hold in their head.

That's the whole cast. Let's meet them.

Step 1 — What is a "moving part"?

WHAT. A moving part is anything in a function that can change the outcome: a variable, an if-branch, a parameter, a dependency on another module. We give the count of these parts a name: the letter $n$ .

WHY a letter? Because we want to talk about "how the difficulty grows as the count changes," and you can't grow a specific number like 3 — you grow a variable. The letter $n$ is just a box we drop the current count into.

PICTURE. Below, each dot is one moving part. On the left a tiny function with $n = 3$ dots; on the right a bloated one with $n = 6$ dots. Nothing connects them yet — we are only counting the dots.

Step 2 — Parts don't sit alone; they interact

WHAT. The trouble with code is never a single part. It's that part A affects part B, which affects part C. To understand the function you must trace these links between parts.

WHY links, not parts? Reading one variable is easy. The hard work is remembering "if this flag is set, then that branch behaves differently, which changes this variable…" — those are relationships. So the real cost lives in the links, and we now start drawing them.

PICTURE. Same dots as Step 1, but now we draw a cyan line for every pair of parts that could affect each other. Watch the left side stay sparse while the right side turns into a web.

Step 3 — Counting the links: the handshake picture

WHAT. We count every line drawn in Step 2. Call that count $C$ (for connections, or cost).

WHY this exact count? Because $C$ is the number of relationships a reader juggles — a far better measure of "hard to understand" than $n$ alone.

HOW we count — the handshake. Imagine $n$ people in a room; each must shake hands with every other person once. Person 1 can shake with the other $n - 1$ people. Person 2 also has $n - 1$ possible partners. So listing all handshakes gives:

$each part n \times every other part (n - 1) = n (n - 1)$

Here:

$n$ = the part starting the handshake,
$(n - 1)$ = everyone else it can reach (it can't shake its own hand — that's why we subtract 1).

PICTURE. Four dots labelled 1–4 arranged in a square, every pair joined. We highlight one dot's $n - 1 = 3$ reaches in amber so you see where the $(n - 1)$ comes from.

Step 4 — Fixing the double-count (why we divide by 2)

WHAT. The count $n (n - 1)$ is too big by a factor of exactly 2. We halve it.

WHY divide by 2? A handshake between A and B is one handshake — but our list counted it twice: once as "A shakes B" and once as "B shakes A". Every link got counted from both ends. To count each unordered pair once, we divide by 2.

PICTURE. One cyan edge between A and B, with two amber arrows on it (A→B and B→A) showing the two counted directions, and a note: "same link, counted twice → divide by 2."

The symbol $(2 n)$ is not new magic — it is a name for the count we just built by hand.

Step 5 — Why this curve bends upward (the quadratic)

WHAT. We now watch what $C$ does as $n$ grows. The answer: it grows like $n^{2}$ — a quadratic, a curve that bends upward, not a straight line.

WHY does that matter? Because straight-line growth would mean "twice the parts, twice the pain" — survivable. Upward-bending growth means "twice the parts, four times the pain." That gap is the entire engineering argument for KISS.

Let's see the bend algebraically. Expand the top: $C = \frac{n ( n - 1 )}{2} = \frac{n ^{2} - n}{2}$ The dominant piece is $n^{2}$ (the $n^{2}$ term grows much faster than the lone $- n$ for big $n$ ). A quantity ruled by $n^{2}$ is quadratic — and quadratics curve up.

Double the parts, $n \to 2 n$ : $C_{new} = \frac{2 n ( 2 n - 1 )}{2} \approx \frac{4 n ^{2}}{2} = 4 \cdot \frac{n ^{2}}{2} \approx 4 C$ The factor 4 is exactly $2^{2}$ : squaring the doubling. That "square" is the shape of the pain.

PICTURE. Two curves on the blueprint grid: a straight amber line (imagined "linear" cost) and the real cyan curve $C = \frac{n ( n - 1 )}{2}$ arcing above it. Points at $n = 3$ ( $C = 3$ ) and $n = 6$ ( $C = 15$ ) are marked — doubling $n$ made $C$ jump 5×, matching the parent note.

Step 6 — The degenerate cases (where the formula must still hold)

A formula you trust must survive its edge inputs. Let's test the smallest and the "empty" cases — the reader must never hit a scenario we skipped.

WHAT / WHY. We plug in $n = 0, 1, 2$ and confirm the count matches plain reasoning.

$n = 0$ (empty function): $C = \frac{0 \cdot ( - 1 )}{2} = 0$ . No parts, no links. ✅ A do-nothing stub has zero cognitive load — correct.
$n = 1$ (one part): $C = \frac{1 \cdot 0}{2} = 0$ . One part can't link to anything but itself, which we excluded. ✅ A single straight-line statement is trivially readable.
$n = 2$ (two parts): $C = \frac{2 \cdot 1}{2} = 1$ . Exactly one link. ✅ Two things, one relationship — the simplest real interaction.

PICTURE. Three tiny panels side by side: 0 dots (no lines), 1 dot (no lines), 2 dots (one line). The formula's output is stamped under each.

Step 7 — Splitting a function: how KISS beats the curve

WHAT. Take one big function with $n = 6$ ( $C = 15$ ) and split it into two honest functions of $n = 3$ each.

WHY this is the payoff. Each small piece costs $(2 3) = 3$ . Two of them cost $3 + 3 = 6$ . So splitting turned 15 links into 6 — a 60% cut in cognitive load, from the same six parts, just because we severed the cross-links between the halves.

$C_{one big} = (2 6) = 15 ⟶ C_{two small} = (2 3) + (2 3) = 3 + 3 = 6$

$15$ — every pair among all six parts entangled.
$6$ — only pairs within each small unit remain; the halves no longer see each other.

This is the mathematical face of "one responsibility per unit" (Single Responsibility Principle) and of guard-clause flattening from the parent note. It is also why Cyclomatic Complexity — a real link-counting metric — drops sharply when you split.

PICTURE. Left: 6 dots fully webbed (15 lines, cyan). Right: the same 6 dots split into two clusters of 3, each internally webbed, no lines crossing the gap (6 lines total). Amber arrow between them: "cut the cross-links."

The one-picture summary

Everything above, compressed: parts → all possible links → count them → halve → watch it bend upward → split to escape the bend.

Recall Feynman retelling — the whole walkthrough in plain words

Picture kids at a party (the parts, $n$ ). The chaos isn't the number of kids — it's the number of friendships they have to keep track of (the links, $C$ ). With 3 kids there are 3 friendships. Add 3 more kids and you don't get 6 friendships — you get 15, because every new kid must befriend everyone already there. That's why one crowded room is a nightmare but two smaller rooms are calm: splitting the party cuts the friendships across the gap. Your code is the party. KISS is choosing two calm rooms over one loud one — not because fewer kids, but because fewer things pointing at each other. The formula $C = \frac{n ( n - 1 )}{2}$ is just the party's friendship-counter, and its upward curve is the reason "a little more complex" always costs "a lot more headache."

Related: YAGNI (don't add parts you don't need yet), DRY (merge proven duplicate parts, not imagined ones), Premature Optimization (clever tricks add hidden links), Code Readability (the real goal $C$ approximates).