Originally posted July 2019. This is a topic I’ll revisit in book 2, since teams will need to synchronize on what they mean by “good”. Watching a design debate play out at work I’ve been struck by the lack of actual concrete feedback about the proposed alternatives. Data wouldn’t eliminate politics and personality from the conversation, but (and here perhaps I am being naive) feedback couldn’t hurt. If it’s me in the room, I’d like to hear something more concrete than, “I don’t like Adapter Factories”.
After reading your latest book, I’ve been thinking a lot about cohesion. In quest for better understanding, I read about linguistic cohesion. Looked for antonyms for it. That lead me to the word”incoherent”.
Cohesion and coherent seem strongly related. By leveraging cohesion something becomes more coherent. It can be reasoned about more easily, more easily elaborated and more easily isolated.
Thanks for helping make the idea more understandable.
Wonderful idea. I especially love how thoughtfully you listed the caveats!
I also think this could be a helpful data point. And I fear that some or all of the caveats will render it useless (or even harmful) in many practical contexts :/
I think I'm seeing some insightful and useful ideas for "objectively" (meaning "*numerically* scoring") evaluating structural changes against a history of functional changes. Would have to be manual work until it could be (partially?) automated.
And it's applicability seems to be limited in cases I commonly work, where we need to make decisions but it's man-weeks or man-months before we'd have code to experiment with. Like yes, we could "spike." But how valid are the numeric results from the spike? As long as we are respectful, rational, and reasonable, a few hours of discussion could be faster and cheaper than man-weeks of implementation, measurement, and then contentious evaluation of the "objective" numeric results.
You could certainly say "for change X design A shows coupling and cohesion like this and design B like that". You could expand that to a history of changes. And changes tend to cluster (until they don’t—see punctuated equilibrium).
Are "number of lines needed for a behavior change" and "locality of change" always the things we want to be optimizing for? Back when I mostly wrote dynamically-typed code, I would have said "yes", but after working with algebraic static type systems for a few years, I see things differently. I find that long-distance connascence is much less of an issue when my type checker tells me all the places I need to update. (Maybe the ease-of-change metrics could account for that? I don't know.)
The thing I mostly optimize for these days is readability. "Can you understand what the code currently does" is more important to me than "are future changes likely to be small". After all, I have to understand the code before I can hope to change it safely. Structure A is better than structure B if someone unfamiliar with both finds A easier to read (i.e. your point about "golf").
Number of lines is only vaguely related to measures we actually care about, like cost, opportunity cost, & profit. Locality of change is more directly related. The less of the system we have to concern ourselves with, the cheaper the change. Locality is part of readability, and having written 2 books on readability you'll never see me come out against.
After reading your latest book, I’ve been thinking a lot about cohesion. In quest for better understanding, I read about linguistic cohesion. Looked for antonyms for it. That lead me to the word”incoherent”.
Cohesion and coherent seem strongly related. By leveraging cohesion something becomes more coherent. It can be reasoned about more easily, more easily elaborated and more easily isolated.
Thanks for helping make the idea more understandable.
Glad you dug into cohesion. Explaining it took me most of the 18 years of writing the book.
The visualizations make me think of fMRIs showing neural activity in brains during cognitive processes
https://en.m.wikipedia.org/wiki/Functional_magnetic_resonance_imaging
Very nice visualizations/descriptions of coupling and cohesion.
Wonderful idea. I especially love how thoughtfully you listed the caveats!
I also think this could be a helpful data point. And I fear that some or all of the caveats will render it useless (or even harmful) in many practical contexts :/
Cooool
I think I'm seeing some insightful and useful ideas for "objectively" (meaning "*numerically* scoring") evaluating structural changes against a history of functional changes. Would have to be manual work until it could be (partially?) automated.
And it's applicability seems to be limited in cases I commonly work, where we need to make decisions but it's man-weeks or man-months before we'd have code to experiment with. Like yes, we could "spike." But how valid are the numeric results from the spike? As long as we are respectful, rational, and reasonable, a few hours of discussion could be faster and cheaper than man-weeks of implementation, measurement, and then contentious evaluation of the "objective" numeric results.
You could certainly say "for change X design A shows coupling and cohesion like this and design B like that". You could expand that to a history of changes. And changes tend to cluster (until they don’t—see punctuated equilibrium).
Are "number of lines needed for a behavior change" and "locality of change" always the things we want to be optimizing for? Back when I mostly wrote dynamically-typed code, I would have said "yes", but after working with algebraic static type systems for a few years, I see things differently. I find that long-distance connascence is much less of an issue when my type checker tells me all the places I need to update. (Maybe the ease-of-change metrics could account for that? I don't know.)
The thing I mostly optimize for these days is readability. "Can you understand what the code currently does" is more important to me than "are future changes likely to be small". After all, I have to understand the code before I can hope to change it safely. Structure A is better than structure B if someone unfamiliar with both finds A easier to read (i.e. your point about "golf").
Number of lines is only vaguely related to measures we actually care about, like cost, opportunity cost, & profit. Locality of change is more directly related. The less of the system we have to concern ourselves with, the cheaper the change. Locality is part of readability, and having written 2 books on readability you'll never see me come out against.