Coupling, Cohesion & Separation of Concerns

If you remember only one idea about design, make it this one. The quality of a design comes down to how its parts relate, captured in two words: coupling and cohesion. They are the single biggest predictor of whether software stays easy to change.

The rule of thumb is short: keep related things together (high cohesion) and keep separate things loosely connected (low coupling). A close cousin, separation of concerns, says each part should do one job. Together they're the difference between software you can change safely and software where every edit breaks something elsewhere.

Picture two kitchens. In one, every appliance is hard-wired into the others, so swapping the toaster means rewiring the fridge. In the other, everything plugs into a standard socket, so you swap any one freely. The second is loosely coupled — and far easier to live with.

Coupling: How Much Parts Depend on Each Other

Coupling is how tightly two parts depend on each other. When parts are tightly coupled, changing one forces you to change the other — they're tangled together. When they're loosely coupled, each can change on its own as long as the connection between them stays the same. Loose coupling is the goal: it means a change stays contained instead of rippling across the whole system.

Cohesion: How Focused a Part Is

Cohesion is how focused a single part is on one job. A highly cohesive module does one thing and contains everything related to that thing — all the reminder logic in the reminder module, and nothing else. A low-cohesion module is a junk drawer: bits of unrelated work jammed together. High cohesion is the goal, and notice it's a different axis from coupling — you want low coupling and high cohesion, not a trade between them.

	What you want	Why
Coupling	Low (loose)	A change in one part doesn't force changes in others
Cohesion	High (focused)	Each part does one job, so it's easy to find and understand

Separation of Concerns

Separation of concerns is the practice that produces low coupling and high cohesion: give each part one responsibility, one "concern", and don't let concerns bleed into each other. The code that talks to the database shouldn't also decide how the screen looks; the reminder logic shouldn't also handle logging in. When each concern lives in its own place, you always know where to make a change — and where not to.

Why It Pays Off

All three ideas serve one payoff: you can change one thing without breaking five others. Software's whole job is to keep changing — new features, fixes, shifts in the world — so a design where changes stay local is a design that survives. This is why coupling and cohesion predict a codebase's future better than almost anything else, and why they sit underneath modularity, microservices, and the SOLID principles still to come.

Cadence's reminder logic lives in its own focused module (high cohesion), connected to the rest of the app only through a simple, stable link (low coupling). When the team later switches reminders from email to push notifications, only that one module changes — the habit code and the streak code never even notice. A change that could have rippled everywhere stays politely in one place. That's the entire point.