@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
For me, your explanation at DDD Europe 2020 (https://youtu.be/3gib0hKYjB0) was good to follow. After watching that talk, I even purchased the green book, but I have to admit, I didn't read it yet. So on the upside, I'm still in for a treat ;)
Reducing coupling and thus reducing the cost of changes, that stuck with me.
Jun 24, 2022·edited Jun 24, 2022Liked by Kent Beck
I think of coupling, or rather de-coupling visually as a gelatinous purple colored blob floating in mid-air, and then slowly being pulled apart from opposite sides by 2 electromagnets into 2 blobs - a red blob and a blue blob, separated in space.
If you can use a (programming) language'ss semantics to guarantee that the impact of a change is limited (scope, for example) then you're confidence level about making changes is going to go up.
But even then things can get you - in Javascript, for example, it's pretty common (sadly) to see people using 'strings' as constant values - without a constant being defined. This leads to rather horrible implicit dependencies that are difficult to track if one of the dependees change. So somewhere in there there should be a rule saying: all dependencies must be explicit...
I always thought coupling/cohesion was as simple as "what changes together stays together" and that stems from this simple concept of economics you speak of. Economics come into play for various reasons. One of them is cognitive load. If the cognitive load is high, the code is hard to change. So, even with decent cohesion, you may want to see if it's splittable, or chunkable as Kent would say, lol. Another economic issue is sometimes things are relatively easy to understand, but they are too intertwined. If that intertwined code gets used a lot, it becomes difficult to change later on.
For me, your explanation at DDD Europe 2020 (https://youtu.be/3gib0hKYjB0) was good to follow. After watching that talk, I even purchased the green book, but I have to admit, I didn't read it yet. So on the upside, I'm still in for a treat ;)
Reducing coupling and thus reducing the cost of changes, that stuck with me.
I think of coupling, or rather de-coupling visually as a gelatinous purple colored blob floating in mid-air, and then slowly being pulled apart from opposite sides by 2 electromagnets into 2 blobs - a red blob and a blue blob, separated in space.
If you can use a (programming) language'ss semantics to guarantee that the impact of a change is limited (scope, for example) then you're confidence level about making changes is going to go up.
But even then things can get you - in Javascript, for example, it's pretty common (sadly) to see people using 'strings' as constant values - without a constant being defined. This leads to rather horrible implicit dependencies that are difficult to track if one of the dependees change. So somewhere in there there should be a rule saying: all dependencies must be explicit...
I always thought coupling/cohesion was as simple as "what changes together stays together" and that stems from this simple concept of economics you speak of. Economics come into play for various reasons. One of them is cognitive load. If the cognitive load is high, the code is hard to change. So, even with decent cohesion, you may want to see if it's splittable, or chunkable as Kent would say, lol. Another economic issue is sometimes things are relatively easy to understand, but they are too intertwined. If that intertwined code gets used a lot, it becomes difficult to change later on.