Coupling and cohesion are two older, foundational concepts in software design — predating most of the specific principles and patterns discussed elsewhere on this shelf — that a great deal of more specific advice is, underneath, actually trying to optimize. Cohesion describes how closely related the responsibilities within a single module are; coupling describes how dependent separate modules are on each other's internal details. The general goal, stated simply, is high cohesion (each module does one clearly related thing) and low coupling (modules depend on each other as little as possible, and only through well-defined interfaces). Related system-design guidance appears in the Microsoft architecture design principles.
Why these two properties, specifically
High cohesion and low coupling matter because they directly predict how expensive change is. A highly cohesive module can usually be understood and modified on its own, because everything relevant to a given responsibility lives in one place. Low coupling means a change to one module is unlikely to require corresponding changes elsewhere, because other modules don't depend on its internal details — only on a stable, well-defined interface. Most of the specific advice covered elsewhere on this shelf — SOLID's Single Responsibility Principle, the Interface Segregation and Dependency Inversion principles, the idea of a deep module from A Philosophy of Software Design — can be understood as specific tactics for improving one or both of these two underlying properties. The same trade-off mindset applies to staffing and workflow design; workforce optimization software explores that operational angle.
This is a useful lens precisely because it cuts through disagreements between more specific pieces of advice: when two design principles seem to conflict in a given situation, asking which choice produces higher cohesion and lower coupling overall is often a more productive tiebreaker than trying to determine which named principle technically applies.
The trade-off that's easy to miss
Coupling and cohesion aren't independent knobs that can both be maximized freely — there's a real trade-off between them. Merging two loosely related pieces of functionality into one module can reduce coupling between them (they're now the same module, so there's no cross-module dependency to manage) but at the cost of cohesion (the merged module now has two less-related responsibilities instead of one focused one). Conversely, splitting a cohesive module into smaller, more specialized pieces can improve cohesion for each piece individually while increasing coupling between them, since they now need to coordinate across a module boundary that didn't exist before.
- When two specific design principles seem to give conflicting advice for a situation, ask which choice produces better overall coupling and cohesion — it's often a clearer tiebreaker than debating which named principle applies.
- Splitting a module doesn't automatically improve a design — check whether the split increased coupling between the new pieces by more than it improved cohesion within each.
- Coupling through a well-defined, stable interface is much less costly than coupling to another module's internal implementation details — not all coupling is equally bad.
- A module with unrelated responsibilities bundled together (low cohesion) is often harder to safely change than a well-coupled pair of focused modules, even though it might look simpler from having fewer files.
Why this framing is more durable than any specific rule
Named principles and patterns come with specific implementation shapes that can go out of fashion, or turn out to be a poor fit for a particular language or paradigm, discussed with respect to design patterns elsewhere on this shelf. Coupling and cohesion, being more abstract and closer to a direct measure of what actually makes a codebase expensive or cheap to change, don't have that problem — the underlying trade-off applies as much to a modern microservices architecture as it did to the object-oriented systems the terms were originally coined for.
This is why coupling and cohesion, despite being older and less specific than most of the ideas discussed elsewhere on this shelf, remain some of the most useful vocabulary in architectural discussions — they describe the actual thing being optimized, rather than one particular tactic for optimizing it.