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.
But you are right, it's hard to explain. I mean I even read what I just wrote, and I think "There's something missing still. People who understand coupling/cohesion will understand, but maybe new folks won't".
If that can be done, it would really add to young developer's ability to predict the future for the code they are writing now. That's a very good thing.
You might be able to guess that I care less about predicting the future than in doing a good job with the present and adapting flexibly to learning and surprises.
So do I. What I meant is that being able to predict that the complexity of the current code is too high, and will cause problems later. :D i.e. predicting the future, but in a loose manner.
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.
Mine is paisley, but whatever works 🤪
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.
But you are right, it's hard to explain. I mean I even read what I just wrote, and I think "There's something missing still. People who understand coupling/cohesion will understand, but maybe new folks won't".
Exactly. That's why I 1) need to write a book about it and 2) I need feedback about that book.
If that can be done, it would really add to young developer's ability to predict the future for the code they are writing now. That's a very good thing.
You might be able to guess that I care less about predicting the future than in doing a good job with the present and adapting flexibly to learning and surprises.
So do I. What I meant is that being able to predict that the complexity of the current code is too high, and will cause problems later. :D i.e. predicting the future, but in a loose manner.