Category: Code Principles

A calm, thorough guide to DRY (“Don’t Repeat Yourself”): the misplaced-home-address analogy, the formal definition centered on knowledge rather than text, its 1999 origins with Andy Hunt and Dave Thomas in The Pragmatic Programmer, the playful WET opposite, the three kinds of duplication (code, logic, knowledge/data), a building-blocks diagram of three copies vs. one single source of truth, four core benefits, a worked TaxPolicy code example, seven techniques for staying DRY, DRY beyond code (documentation, tests, design systems, infrastructure), the Rule of Three, the over-abstraction trap and the AHA counter-principle, the “wrong abstraction” trap where coincidental similarity backfires, how DRY relates to KISS / SRP / Composition, a six-step spot-and-fix recipe, a comparison table, common pitfalls, real-world analogies (single light switch, master recipe card), an FAQ, and a glossary.

A calm, thorough guide to KISS (“Keep It Simple, Stupid”): the three-button-vs-forty-two-button remote analogy, the formal definition (a test not a ban), its origin around 1960 with Kelly Johnson at Lockheed’s Skunk Works and later adoption by the U.S. Navy, the crucial simple-vs-easy distinction, a building-blocks diagram of a six-part notification pipeline vs. one clear function, four core benefits (fewer bugs, faster onboarding, easier debugging, cheaper to change), a worked DiscountStrategy code example contrasting an over-engineered version with a one-line simple version, six techniques for staying simple (solve today’s problem, prefer plain language, cut ruthlessly, favor small pieces, say no to just-in-case, write down why), KISS in visual design and UX, KISS in project management, the essential-vs-accidental complexity distinction, how KISS relates to DRY / YAGNI / Occam’s Razor, when simple becomes simplistic, a six-step simplifying recipe, common pitfalls, real-world analogies (kitchen knife, capsule wardrobe, junk drawer vs. toolbox), an FAQ, and a glossary.

A calm, thorough guide to YAGNI (“You Aren’t Gonna Need It”): the overstuffed-suitcase and lemonade-stand analogy, the formal definition (build for confirmed present need, not guessed future need), its Extreme Programming origins with Kent Beck, Ron Jeffries and the Chrysler C3 payroll project, the four hidden costs of building early (cost to build / cost of delay / cost of carrying / cost of getting it wrong), a building-blocks diagram of a speculative multi-channel notification design vs. a single-purpose one, four core benefits, a worked currency-converter code example, five practical habits for applying YAGNI (asking the one question out loud, spotting the “we might need this later” trigger phrase, waiting for the second and third case, separating quality from speculation, scoping down bloated pull requests), YAGNI and reversibility (safe to defer vs. worth extra care upfront), the supporting practices YAGNI depends on (refactoring, testing, CI), how YAGNI relates to KISS / DRY / MVP, common failure modes, YAGNI in the age of AI coding tools, a five-step decision recipe, common pitfalls, everyday real-world analogies, an FAQ, and a glossary of key terms.

A complete guide to why deep inheritance hierarchies become problematic in software design: the tall-apartment-building analogy, an honest look at what counts as “deep” (1-2 / 3-4 / 5+ levels), the four core problems (fragile base class amplified, the yo-yo problem, compile-time rigidity, leaky encapsulation), a step-by-step walkthrough of a Vehicle > MotorVehicle > Car > ElectricCar > SelfDrivingElectricCar chain deepening one reasonable step at a time, real-world examples across GUI toolkits, enterprise systems, textbook Animal hierarchies, and game engines, an honest look at when some depth actually helps, four practical questions for judging “how deep is too deep” in your own codebase, and a five-step plan for flattening a deep hierarchy safely into composed pieces.

A complete guide to the Liskov Substitution Principle: what it says, the hidden contract of preconditions/postconditions/invariants, the classic Rectangle-Square trap, everyday violations (birds, files, payments), how to spot them, how to fix them (split abstractions, favour composition), and how LSP interlocks with the other SOLID principles.

Add new behaviour without touching what already works. That is the whole promise of the Open/Closed Principle — the “O” in SOLID. This thirteen-chapter guide unpacks the formal definition from Bertrand Meyer, what “open” and “closed” each really mean, why it matters, four reliable warning signs of a violation, a full before-and-after Python refactor from an if/elif chain into a proper abstraction, the abstraction-and-polymorphism mechanism behind the whole thing, the plugin and strategy extension patterns, pros and cons, common pitfalls, everyday examples, an FAQ, and a seven-line takeaway.

One class, one job, one reason to change. It sounds almost too simple to matter — until you see what happens to a codebase when nobody bothers to follow it. This thirteen-chapter guide takes a deep dive into the “S” in SOLID: the formal definition from Robert C. Martin, what “reason to change” really means, why the principle matters, five reliable code smells that signal a violation, a full before-and-after Python refactor, how the same idea scales from functions to modules, its relationship to testing, pros and cons, common pitfalls, an FAQ, and a seven-line takeaway summary.

Five short letters — S, O, L, I, D — five simple habits, and decades of hard-won wisdom about writing code that does not fall apart the moment it needs to grow. This thirteen-chapter guide walks through what each letter really means in plain language: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. Includes an analogy, a Python example, and a “why it matters” callout for each principle, plus how the five work together in a real payment feature, pros and cons, pitfalls, everyday software examples, an FAQ, and a six-line takeaway.