Don't Panic — Software Design Principles

Here is the two-minute version of what a whole subfield of programming folklore is actually about: guidelines for which code structures stay cheap to change, and which ones quietly make every future change more expensive. The best-known pieces of that folklore go by acronyms — SOLID (five rules for object-oriented structure), DRY (don't repeat yourself), KISS (keep it simple), YAGNI (you aren't gonna need it) — because they got popular enough to earn one.

The problem underneath all of it is unglamorous but expensive. Software costs money twice — once to write, and continuously afterward to change. Two things drive that second cost: how much of the system you have to understand before touching one line, and how far your change ripples once you make it. Before anyone wrote these principles down, teams learned this the hard way, usually around year two, when the part of the codebase nobody thought was related to anything turned out to be load-bearing.

The move underneath everything else here is separation of concerns — Edsger Dijkstra's 1974 argument for studying one aspect of a problem in isolation without forgetting the rest exist. Coupling and cohesion are how you check whether that separation actually worked: how much one module depends on another's internals, and whether the things inside one module belong together. SOLID is what the same idea looks like once you're specifically writing object-oriented classes.

Here is the part that surprises people expecting a checklist: these principles fight each other, on purpose, all the time. Merge two things too eagerly under DRY and you can break Single Responsibility. Wrap everything in an interface "for later" and you have satisfied Open-Closed while violating YAGNI, a principle that exists specifically to stop you doing that. There is no setting where every principle is simultaneously maxed out, and treating this as a checklist to max out is itself the standard mistake. An interface with exactly one implementation and no second one coming is not discipline, it is a tax with no service behind it.

Even DRY, the one that sounds most like arithmetic, is not really about deleting duplicate lines. It is about not encoding the same fact in two places. Two functions that look alike today can be checking unrelated rules that drift apart tomorrow, and merging them early creates a worse problem than the duplication did — carrying the duplication is usually the cheaper mistake.

None of this is memorization, and nobody is grading you on reciting the acronyms in order. It is judgment about which principle is under the most pressure in the specific decision sitting in front of you right now, and which one you are tempted to apply for the wrong reason. The Cheatsheet has the fast lookup table for when you already know roughly what you are looking for. The Practice Reference turns each principle into something you actually do during a code review instead of something you nod at. Field Notes covers where this judgment gets genuinely hard in practice, including a real, measured performance cost hiding inside one of the SOLID principles that the standard advice never mentions.

Don't Panic — Software Design Principles

Relevant careers