August 20, 2024

coupling as co-explanation

For many in the software industry, "coupling" is a dirty word.

Previously, I provided a brief introduction to this newsletter, and then analyzed the structure of explanations in software development.

---

For many in the software industry, "coupling" is a dirty word. This dates back to a 1974 paper entitled Structured Design¹, which asserted that the goal of software design was to minimize coupling and maximize cohesion.

The authors defined coupling as "relationships among modules" and cohesion as "relationships among elements in the same module." This distinction was objective, delineated by the syntactic boundaries of our code.

But which syntactic boundaries? According to the paper, modules were "PL/I procedures, FORTRAN mainlines and subprograms, and, in general, subroutines of all types." In other words, functions.

No one, however, gave this much weight. When object-oriented programming came into vogue, people talked about the need for cohesive classes.² Others talked about cohesion within components, or entire systems.³

And this makes sense. We want our software to feel cohesive, at every level. We want the disparate parts to fit together.

But according to the original paper, this is impossible. Cohesion exists between "elements in the same module." These elements cannot, themselves, be modules. Otherwise, our cohesion becomes their coupling.

And so, the meaning of cohesion has changed. It is no longer the simple, explicit concept offered by the original paper. Instead, we're told that we can intuit when code lacks cohesion; it simply "doesn't feel right."⁴ Cohesion has become a tacit concept.

This retreat into tacit knowledge isn't all bad. Cohesion offers a way to discuss and refine our intuitions about software design. Most discussions of cohesion, however, fall short of this. Often, they can be reduced to a bare tautology: coupling is good, except when it isn't.

This newsletter aims to change that. We can begin by defining coupling as co-explanation. The degree of coupling between any two things is determined by how often they're explained together.

If two things are regularly co-explained, it's because their meaning is intertwined. Understanding one requires understanding the other. Changing one requires changing the other. They are, in other words, coupled.

This coupling has a cost; when we explain one, the other comes along for the ride. It also, however, has a benefit; coupling creates explanatory power. When we explain one, we begin to explain the other.

Coupling is an invaluable tool in software design. It's our job — perhaps our only job — to recognize when the benefits outweigh the costs. Next week, we will look at some examples of beneficial coupling, and try to understand how it works.