KISS — Keep It Simple: Exercises — Coding deep dive

Before we start, we earn two tools from zero: what counts as a moving part, and the load formula $C$ .

Definition The counting rule — what is ONE "moving part"?

To make $n$ objective instead of a vibe, we fix a rule and use it on every exercise below. A "moving part" is any named thing a reader must hold in their head to trace one path through the code. Concretely, count +1 for each of these, and nothing else:

each variable or parameter the code reads or writes (score, base);
each branch point — an if, elif, while, for, case, or short-circuit and/or (the condition is the part, not the two arms);
each named code unit that participates on the path — a function, method, class, or interface the reader must open or understand to follow the logic. What we do NOT count: return/else keywords (they carry no new decision), literals, and comments. Why this rule? Every item above is a place where behaviour can branch or vary, so it is exactly a "thing that can interact with another thing" — which is what the pair count $C$ measures. Whenever an exercise reports an $n$ , it is applying these three bullets.

Figure 1.

L1 — Recognition

Worked example Exercise 1.1 — Spot the violation

Which snippet violates KISS (Keep It Simple, Stupid), and name the specific smell?

# A
def is_even(x): return x % 2 == 0
# B
def is_even(x): return bool(1 - (x & 1)) if x is not None else (_ for _ in ()).throw(ValueError)

Recall Solution 1.1

B violates KISS. The smell is cleverness over clarity (a "slick one-liner").

x & 1 is a bit-trick for parity that most readers must decode.
The generator-that-throws ((_ for _ in ()).throw(...)) is a cryptic way to raise an error. WHAT we did: compared two solutions to the same problem. WHY: KISS is about the simplest thing that solves the problem — both are correct, but A reads like English. Fix: keep A.

Worked example Exercise 1.2 — Count the moving parts

Apply the counting rule (variables + branch points + participating units) to get $n$ , then compute $C$ .

def grade(score):          # variable: score
    if score >= 90:        # branch point
        return "A"
    if score >= 80:        # branch point
        return "B"
    return "C"

Recall Solution 1.2

Apply the rule bullet by bullet: score is 1 variable (bullet 1); the two ifs are 2 branch points (bullet 2); no other function/class is opened (bullet 3 contributes 0); return keywords are not counted. Total $n = 1 + 2 = 3$ . $C = \frac{3 \cdot 2}{2} = 3.$ WHY this is fine: $C = 3$ is tiny — this is already KISS-clean via early returns.

L2 — Application

Worked example Exercise 2.1 — Refactor to guard clauses

Rewrite with early returns, then report $n$ and $C$ before vs after. (Assume the 3 conditions are the only pieces.)

def can_ship(order):
    if order:
        if order.paid:
            if order.in_stock:
                return True
    return False

Recall Solution 2.1

def can_ship(order):
    if not order:          return False
    if not order.paid:     return False
    if not order.in_stock: return False
    return True

Counting. By the rule, each version has 3 branch points (the three conditions) and no extra variables/units, so $n = 3$ and $C = \frac{3 \cdot 2}{2} = 3$ for both. A sharper metric — "live pairs" $L$ . The total $C$ counts every pair across the whole function; but a reader only truly juggles the branches that are open at once. So define a second quantity.

== $L_{open}$ = the number of if blocks that are still open (entered but not yet exited) at the single deepest point of the function.== It is a plain integer you get by pointing at the most-indented line and counting the ifs stacked above it.
==Live pairs $L = (2 L _{open}) = \frac{L _{open} ( L _{open} - 1 )}{2}$ == — the pair-count among only those simultaneously-open branches. (Same $(2 \cdot)$ machine as $C$ , but fed $L_{open}$ instead of $n$ .) Now measure both versions:
Nested version: at the innermost line, all 3 if blocks are open $\Rightarrow L_{open} = 3 \Rightarrow L = (2 3) = \frac{3 \cdot 2}{2} = 3$ .
Guard-clause version: each if returns immediately, so at most one if is open at any moment $\Rightarrow L_{open} = 1 \Rightarrow L = (2 1) = 0$ . Same total $C = 3$ on paper, but live pairs $L$ drop from 3 to 0 — that is the concrete, countable win of guard clauses.

Worked example Exercise 2.2 — Kill the speculative flag

A teammate added verbose=False "in case we need logging later." No caller ever passes it. Should it stay? Justify with a principle name.

def save(user, verbose=False):
    db.write(user)
    if verbose:
        log(user)

Recall Solution 2.2

Delete verbose and the if.

def save(user):
    db.write(user)

Principle: YAGNI ("You Aren't Gonna Need It") — a way to achieve KISS by not building for imagined futures. Counting the win (by the rule): before, user and verbose are 2 variables and the if verbose is 1 branch point $\Rightarrow n = 3 \Rightarrow C = 3$ . After, only user remains, $n = 1 \Rightarrow C = \frac{1 \cdot 0}{2} = 0$ . We removed all 3 tracked interactions.

L3 — Analysis

Recall Solution 3.1

Before (one big function): $C_{before} = \frac{40 \cdot 39}{2} = 780.$ After (five functions, $n = 8$ each): $C_{one} = \frac{8 \cdot 7}{2} = 28, C_{after} = 5 \times 28 = 140.$ Reduction factor: $\frac{780}{140} \approx 5.6 \times .$ WHY it works: we kept the same total pieces (40) but broke the giant pair-web into 5 small isolated webs. Because $C$ is quadratic, five small squares are far smaller than one big square. This is the mathematical heart of Single Responsibility Principle.

Figure 2.

Recall Solution 3.2

(a) Internal. Each function has $n = 1 \Rightarrow C_{one} = \frac{1 \cdot 0}{2} = 0$ , so $40 \times 0 = 0$ internal interactions. (b) Cross-function. The coordinator must now hold 40 sub-calls in its head — by the counting rule those 40 called units are 40 moving parts of the coordinator. Their interaction count is $C_{coord} = (2 40) = \frac{40 \cdot 39}{2} = 780.$ The lesson, now numeric: we drove internal load to 0 but recreated the exact same 780 as coordinator load — complexity was moved, not destroyed (indeed here, not even reduced). You cannot win by splitting into dust; you only relocate the tangle to the glue. This is Premature Optimization applied to structure.

Recall Solution 3.3

(a) Internal after split: two groups of 3 $\Rightarrow 2 \times \frac{3 \cdot 2}{2} = 2 \times 3 = 6$ internal pairs. (b) Cross-function pairs: the coordinator tracks 2 sub-calls $\Rightarrow \frac{2 \cdot 1}{2} = 1$ pair. (c) Grand total: $6 + 1 = 7$ . Confirming "moved, not deleted": the original 15 internal pairs did not vanish — 9 of them dissolved because pieces in different groups can no longer interact, but a new cross-function pair (the coordinator's 1) appeared to glue the groups back together. Complexity dropped from 15 to 7 here because the isolation saving beat the glue cost — but that glue cost is real and non-zero (and in Ex 3.2 it swallowed the entire saving), which is exactly why infinite splitting backfires.

L4 — Synthesis

Worked example Exercise 4.1 — Two principles pull opposite ways

You have this duplicated logic in two files:

# file A
price = base + base * 0.18   # 18% GST
# file B
price = base + base * 0.18

A junior wants a TaxCalculatorFactory with pluggable strategies "for future tax types." What does KISS + DRY + YAGNI jointly recommend? Give the code and count $C$ .

Recall Solution 4.1

Joint recommendation: remove the duplication (DRY) with the simplest thing that works (KISS), and refuse the factory (YAGNI) because there is exactly one tax type today.

GST_RATE = 0.18
def with_gst(base):
    return base + base * GST_RATE

Counting the simple version (by the rule): base (variable) + GST_RATE (variable) = 2 parts, no branches, no other units opened $\Rightarrow n = 2 \Rightarrow C = \frac{2 \cdot 1}{2} = 1$ . Counting the factory version — apply the rule to high-level constructs. Bullet 3 of the counting rule says each named unit the reader must open counts +1. A class, a factory method, and an interface are each such a named unit, so they each cost +1 (a reader genuinely must open every one to trace how a price is computed). Enumerating them:

TaxStrategy interface — a named unit (bullet 3)
GSTStrategy concrete class — a named unit (bullet 3)
TaxCalculatorFactory class — a named unit (bullet 3)
create() factory method — a named unit (bullet 3)
the registry dict mapping tax-type → strategy — a variable (bullet 1)
calculate() strategy method — a named unit (bullet 3)
base — the input variable still threaded through (bullet 1) That is $n = 7$ $\Rightarrow C = \frac{7 \cdot 6}{2} = 21$ . So the factory costs 21 vs 1 — 21× the interactions to deliver one fixed 18% rate. Why DRY and KISS agree here: DRY says "one source of truth," KISS says "make that source the simplest possible" — a single function with a named constant, not a framework.

Recall Solution 4.2

Not KISS — it's over-simplification (a bug). The "insufficient funds" check is a needed piece of the problem, not accidental complexity. Removing it makes the code simpler and wrong. Corrected statement (Einstein's razor): as simple as possible, but no simpler. KISS removes unnecessary complexity; a required correctness check is necessary complexity. Rule of thumb: if deleting a piece changes what the program does on valid inputs, it wasn't excess — leave it in.

L5 — Mastery

Recall Solution 5.1

Version X (one function): $C_{X} = (2 12) = \frac{12 \cdot 11}{2} = 66.$ Version Y (sum over 3 leaves + 1 coordinator): $C_{leaf} = (2 5) = \frac{5 \cdot 4}{2} = 10 \Rightarrow 3 \times 10 = 30,$ $C_{coord} = (2 3) = \frac{3 \cdot 2}{2} = 3,$ $C_{Y} = 30 + 3 = 33.$ Verdict: $Y$ is simpler by the count. Factor $= \frac{66}{33} = 2.0 \times$ . What the coordinator term teaches: the split halves total pair-load here — but the coordinator's $C = 3$ is the price of splitting (the same glue we counted in Ex 3.2–3.3). If the leaves had been smaller, that fixed coordinator cost could have eaten the saving. So the mastery habit is: always add the coordinator into the total, never compare leaves alone.

Recall Solution 5.2

Total: $C (k) = k \cdot \frac{( n / k ) ( n / k - 1 )}{2} + \frac{k ( k - 1 )}{2}$ , with $n = 20$ .

$k = 2$ (groups of 10): leaves $2 \cdot \frac{10 \cdot 9}{2} = 90$ ; coord $\frac{2 \cdot 1}{2} = 1$ ; total $= 91$ .
$k = 4$ (groups of 5): leaves $4 \cdot \frac{5 \cdot 4}{2} = 40$ ; coord $\frac{4 \cdot 3}{2} = 6$ ; total $= 46$ .
$k = 5$ (groups of 4): leaves $5 \cdot \frac{4 \cdot 3}{2} = 30$ ; coord $\frac{5 \cdot 4}{2} = 10$ ; total $= 40$ . Minimum here: $k = 5$ (total 40). WHAT this teaches: as $k$ rises, leaf-load falls fast (quadratic shrink of each group) but coordinator-load rises. There is a sweet spot, not "split forever." The curve below plots $C (k)$ — it dips then eventually turns back up. This is the quantitative version of "split until each unit has one job, then stop."

Definition Edge case — when

$n$ is not divisible by $k$ (uneven splits) The tidy formula $C (k) = k \cdot \frac{( n / k ) ( n / k - 1 )}{2} + \frac{k ( k - 1 )}{2}$ assumes every group has exactly $n / k$ pieces. Real splits rarely divide evenly. How to count the remainder: distribute the leftover pieces one-per-group. With $n$ pieces in $k$ groups, let $r = n mod k$ be the remainder. Then $r$ groups get $⌈ n / k ⌉$ pieces and $k - r$ groups get $⌊ n / k ⌋$ pieces, and you sum $(2 \cdot)$ over each actual group size: $C (k) = r (2 ⌈ n / k ⌉) + (k - r) (2 ⌊ n / k ⌋) + (2 k) .$ Example ( $n = 20$ , $k = 3$ ): $20 = 3 \cdot 6 + 2$ , so $r = 2$ : two groups of 7 and one group of 6. Leaves $= 2 (2 7) + 1 (2 6) = 2 \cdot 21 + 15 = 57$ ; coordinator $= (2 3) = 3$ ; total $= 60$ . Why spread the remainder evenly? Because $(2 n)$ is convex — piling the leftovers into one fat group raises its pair-count faster than spreading them thins it, so even splits keep total $C$ lowest.

Figure 3.

Recall Grand recap — the ladder you just climbed

L1: Spot cleverness/over-flagging; complexity ≠ line-count.
L2: Apply guard clauses and YAGNI to drop $n$ ; live pairs $L$ fall from 3 to 0.
L3: Splitting cuts $C$ super-linearly — but you move load to coordinator glue, never delete it (split into 40 → all 780 pairs land on the coordinator).
L4: DRY, KISS, YAGNI cooperate; "no simpler" protects needed edge cases.
L5: There's a mathematical sweet spot to splitting (even for uneven $n$ ); let responsibility, not the raw number, pick boundaries.