tl;dr Coupling (& later Cohesion)

@BethCodes shared this simple summary of coupling and cohesion:

how many things change, with each additional thing making the change less safe, and how much of each thing, with more of each thing making the change safer

I’ve actively been trying to explain coupling & (much harder) cohesion for more than a decade. The work behind Tidy First? began in earnest in 2009. I remember giving a presentation in Israel around that time, trying to explain coupling & cohesion, & receiving the unmistakable feedback that the explanation failed. I appreciate new takes.

I read @BethCodes’ summary, said “Amen! 🙌”, and then said “Wait, what?” Here I’ll unpack what the explanation above means to me.

The economic goal of software design is to balance the cost of coupling versus the cost of decoupling. “Coupling” is the “how many things change” part of the quote above. If I change this element & as a result I have to also change that element, those two elements are coupled with respect to that change.

If that’s as far as the changes went, coupling wouldn’t matter. Coupling cascades. Most changes are small. When the avalanche starts, tho, the changes, while initially small, compound to become enormous compared to “ordinary” changes.

@BethCodes summary focuses on safety, that is (as I understand it) when I change behavior in one way, does behavior change elsewhere in the system in an undesirable way. Do I break shit?

Safety is a big part of the cost. Safety records the likelihood that you’ll be done paying when you think you’re done paying. When you’ve made an unsafe change, you pay much more to find, fix, & apologize to users for the times you make a mistake.

A second part of the cost of unsafe changes are the changes you don’t even attempt because you are (rightly) afraid of the cost of mistakes. This opportunity cost can dwarf the costs of the actual mistakes.

Reducing coupling doesn’t necessarily reduce the risk of making a mistake when changing a single element. Reducing coupling reduces the number of elements changing at once & reduces the chances that you’ll miss one of the elements that need to change in sync.

Next we’ll talk about the second clause in @BethCodes’ quote, the one I’ve had a much harder time explaining: cohesion.