Software Design Principles

A working program is not the same thing as a well-designed one. Design principles are the accumulated judgment of the software field about which structures keep a codebase changeable, and which ones quietly make every future change more expensive. You apply them while writing a class, reviewing a pull request, or deciding how to split a module — not as a one-time architectural decision, but as a running habit.

None of these principles are laws of nature. They are heuristics distilled from decades of watching systems succeed and fail. Treat them as a shared vocabulary for describing why one design is easier to live with than another, and as a set of questions to ask before you commit to a structure.

Why design principles exist

Software costs money twice: once to write, and continuously to change. Requirements shift, teams rotate, and the parts of a system that seemed unrelated on day one turn out to depend on each other by year two. Design principles exist to keep the second cost from spiraling.

Two forces drive that cost more than any other: how much of the system you have to understand to make one change, and how far a change ripples once you make it. Every principle in this course is really an answer to one of those two problems.

The foundational lens: separation of concerns

In 1974, Edsger Dijkstra described the discipline of studying one aspect of a problem "in isolation for the sake of its own consistency," while still knowing that other aspects exist and matter. He called this the separation of concerns, and called it "the only available technique for effective ordering of one's thoughts."