More on this book
Kindle Notes & Highlights
In theory, there is no difference between theory and practice, while in practice there is.
Benjamin Brewster, a student at Yale writing in an 1882 edition of the Yale Literary Magazine
The source of the theory of coupling and cohesion is usually attributed to my book with Ed Yourdon, Structured Design (Yourdon Press, 1975; Prentice Hall, 1979), although it can be traced all the way back to a 1968 conference presentation in Cambridge, Massachusetts.
Coupling and cohesion are simply measures of the complexity of computer code, not from the perspective of the computers executing the programs but that of human beings trying to understand the code.
It is easier to understand the immediate piece of code if it all hangs together, if it makes sense as a whole, if it forms what cognitive psychologists call a gestalt. That’s cohesion.
It is also easier to understand it in terms of its relationships with other pieces of code if these relationships are few and relatively weak or highly constrained. That’s coupling.
Software design is a powerful tool to ease pain in the world—if it is used well. Used badly, it becomes just another instrument of oppression, and a drag on the effectiveness of software development.
Tidy First? also begins describing the theory behind software design: coupling, cohesion, discounted cash flows, and optionality.
Speculative design
Reactive design
“Based on, concerned with, or verifiable by observation or experience rather than theory or pure logic.”
My general learning strategy is to go from concrete to abstract.
“Refactoring” took fatal damage when folks started using it to refer to long pauses in feature development.
They even eliminated the “that don’t change behavior” clause, so “refactoring” could easily break the system.
Now I can say what I mean by “software design”: beneficially relating elements.
From this perspective, software designers can only: Create and delete elements. Create and delete relationships. Increase the benefit of a relationship.
When I talk about the structure of the system, I’m talking about: The element hierarchy The relationships between elements The benefits created by those relationships
Software creates value in two ways: What it does today The possibility of new things we can make it do tomorrow
“What it does today” is the system’s behavior—calculating
How are we going to get to that better machine? In a word, optionality. The mere presence of a system behaving a certain way changes the desire for how the system should behave (Heisenberg’s uncertainty principle).
The cost of changes skyrockets. Instead of being able to exercise an option a day, you can only exercise an option a month. Fewer options, less value. Nothing in the scope of this book directly addresses the first two of these options killers, but we can react to the third. We can keep the kitchen clean as we cook.
The structure of the system doesn’t matter to its behavior.
The structure could make it easy to add new countries to our paycheck calculation, or it could make it hard.
Here’s the problem: structure is not legible in the same way behavior is legible.
Even though we know that we have to invest in structure to maintain and expand optionality, we can’t really tell if we have.
Start by understanding that structure changes and behavior changes are both ways to create value, but that they are fundamentally different. How? In a word, reversibility.
The nature I learned consisted of two surprising properties: A dollar today is worth more than a dollar tomorrow, so earn sooner and spend later. In a chaotic situation, options are better than things, so create options in the face of uncertainty. These two strategies conflict at times. Earning money now can reduce future options. But maybe if you don’t earn money now, you won’t be around to exercise those future options.
They noticed that the expensive programs all had one property in common: changing one element required changing other elements.
They dubbed this change infection property “coupling.” Two elements are coupled with respect to a particular change if changing one element necessitates changing the other element.
... // changing the formatting of the body requires no changes to call sites The second comment here emphasizes an important nuance of coupling: we can’t just say that two elements are coupled. To say something useful, we have to also say coupled with respect to which changes.
If two elements are coupled with respect to a change that never happens, then they aren’t coupled in a way that should concern us. That coupling is the boulder at the top of the hill that never rolls down to crush the village.
If coupling were only ever between two elements, then it wouldn’t haunt our nightmares. Instead, coupling has two properties that drag it center stage: 1–N One element can be coupled with any number of other elements with respect to a change. Cascading Once a change has rippled from one element to another, that implied change can trigger another round of changes, which can themselves trigger changes of their own.
Meilir Page-Jones used the word “connascence” to describe coupling in his book What Every Programmer Should Know About Object-Oriented Design (Dorset House).
The future value of a system reveals itself in today’s realities, not yesterday’s speculation.
Coupled elements should be subelements of the same containing element. That’s the first implication of cohesion.
Parnas, David Lorges. Software Fundamentals: Collected Papers by David L. Parnas. Edited by Daniel M. Hoffman and David M. Weiss. Boston: Addison-Wesley Professional, 2001.
Petre, Marian, and Andre Van Der Hoek. Software Design Decoded. Cambridge: MIT Press, 2016.
Seemann, Mark. Code That Fits in Your Head. Boston: Addison-Wesley Professional, 2021.
Weinberg, Gerald M. The Psychology of Computer Programming. New York: Dorset House, 1998.
