Downside of Design as Increasing Cohesion & Reducing Coupling
My last post on pushback seemed a little dark to me. I like to be constructive when possible, so I’ll try to restate my position in a way that invites conversation. I hope you’ll join in.
I can summarize Empirical Software Design as:
Constantine’s Equivalence states that the cost of software is the coupling in the system.
Optimizing cost requires balancing the cost of coupling & the cost of decoupling under conditions of uncertainty.
Consider eliminating coupling that does or will increase costs.
Strongly consider increasing cohesion.
(The above occurs as an exercise in human relationships, which is out of scope for today’s question.)
Experienced designers pushed back on this, saying they had other criteria for “What goes together?”, “What gets separated?”, and “How big should elements be?” The phrase that kept coming up was “functionally related”, as in, “I want sub-elements that are functionally related.”
Okay, now I can ask the questions:
What is the downside of replacing “functionally related” as the criterion with “increase cohesion, eliminate coupling” as the criterion for design choices?
What exactly does “functionally related” mean? Can someone give me examples of things that are functionally related, & things that might seem functionally related but aren’t?
I’ll have a final chapter on cohesion out later this week. Then a conclusion & introduction & the draft is complete!
“increase cohesion, eliminate coupling” usually creates more smaller modules. Functionally related is normally just a paraphrase for "most changes are done by one team". So it is more on the line of does one thing in reality vs has one reason to change. Functionally modules create less overhead and since all is done with one team the missing decoupling is of no relevance.
The downside of replacing “functionally related” as the criterion with “increase cohesion, eliminate coupling” as the criterion for design choices is the coding overhead and that the required outcome has to be broken apart in more tasks which requires more pre-planning. The upside is usually easier testing, scalability of development, less time on-boarding of new developers and making it harder for cruft to emerge.
If things are "functionally related" they are/ought to be "coupled". These feel like the same concepts to me. How are they different? If I'm in one area, I don't have to think about another area because it is not related, it is not coupled. I can operate without bumping into it.
“What goes together?”, “What gets separated?”, are the right questions... Because we can't always work on The Whole. We have to be able to separate where our changes our bounded to a context and won't ripple out beyond that.
“How big should elements be?" feels entirely irrelevant. It is as large as it is required to be. No larger.