KISS

The Problem It Solves

A one-line regex validates emails. Six months later it rejects a legitimate address; the only developer who understands it left; the fix attempt breaks three test cases nobody can explain. Complexity inserted for elegance, job security, or “future flexibility” charges interest forever — paid by every reader, debugger, and reviewer after the author moves on.

KISS is the discipline of choosing the simplest solution that fully works, treating added sophistication as a cost requiring justification — not a default.

What Simplicity Means Here

• Fewest moving parts that satisfy current requirements.
• Boring constructs: plain loops over stream-gymnastics when clarity suffers; early returns over nested ternaries.
• One obvious way through the code: a reader should predict behavior without executing it mentally twice.

 SAME BEHAVIOR, TWO READS

 status = (a ? b : c) ? x() : y();          if (cond1) {                 │
                                            } else if (cond2) {          │
 read 1: inner ternary → value?             } else {                     │
 read 2: outer ternary → call?                  // each branch obvious
 mental execution × 4 paths                    }
                                            mental execution = linear

Both compile identically. Only one survives review at 3 a.m. during an incident.

Where KISS Gets Violated

Violation	Looks like	Cost
Cleverness	Bit-tricks, regex golf, one-liner obsession	Undebuggable by successors
Framework gravity	Microservice + queue for a cron job’s workload	Operational burden forever
Speculative generality	Strategy pattern for one never-varying algorithm	Indirection tax
Micro-optimization	Caching before measuring	Correctness risk for phantom gains

When Complexity Is Justified

KISS is not minimalism theater — some problems are genuinely complex:

• Real, measured performance requirements (the O(n²) join actually shows in profiles).
• Genuine concurrency (locks exist because races exist).
• Security boundaries (explicit validation layers earn their weight).

The test: complexity justified by a stated requirement or measurement, not by taste. “This caching layer cut p99 from 800ms to 90ms in load tests” justifies itself; “we might need it someday” does not.

Interview Application

• Interviewers penalize both extremes: naive solutions ignoring stated constraints and enterprise architectures for toy problems.
• Saying the simple thing first, then extending under follow-ups, outperforms predicting every requirement upfront.
• The scoring phrase: “simplest version that meets these constraints; here’s where I’d complicate if X were required.”

Failure Modes

• Simplifying away error handling at trust boundaries — that is not simplicity, it is a bug with fewer lines.
• Simplifying past correctness (skipping validation because “inputs are trusted”) — never allowed.