FREE 'How To Evolve Your Software Architecture' Guide: How to work in ways that keep stuff easy to change which gives you the freedom to make mistakes and experiment and how to work in small steps that allow you to determine their fit for your present understanding of the problem... continuously. All explained in this FREE compact guide. Download HERE ➡ www.subscribepage.com/evolve-your-architecture
This is good advice. Especially where the emphasis is on identifying areas where tight coupling is called for. I've seen projects fall to excessive cross talk and tragedy of the commons due to an irrational fear of any coupling whatsoever. The good part is that tight coupling is typically obvious compared to the much more subtle work of maintaining proper loose coupling. Loose coupling requires good discipline, and the ability to wear many hats within a system in order to understand zones of ownership and concern, and formalizing hand off between systems and domains. Fear of coupling at the start inevitably leads to shortcuts later on, with do-everything systems trouncing service-level tables in databases, internal members or state, or otherwise deep intertwined logic from a lack of formal exchange mechanisms that selective tight coupling helps illuminate.
I create modules within each main system object. This permits me to await for another module to load, and all relevant code and public methods are defined here. Since then I've been able to rapidly develop large systems. I've been programming for 19 years and it's completely revolutionised my development.
The best definition of coupling I've come across is that if you have two code elements A and B they are coupled if a change in either forces a change to be made to the other. A and B can then said to be coupled with respect to that particular change.
You've got to do a video on entropy next time. I'd like to hear your take on cohesion and proper use of words from a DDD standpoint. Words and language skills are kind of underestimated in software. They're really powerful in my opinion.
Great vid. Your REST API example serves as a sort of materialization of design by contract, which is very OK in my book. It also falls into Allan Kay's "message passing" view which, again, is very OK as far as I'm concerned. As far as the contract and the message is properly documented both sides can go on their merry way and do whatever they have to do on their side. And you can extend it without breaking it by simply adding more endpoints (or versions of). And if you think of it as simply a "boundary between components", you can extend the concept to anything. IMHO, this is where "classic OOP" does a great disservice by not saying that separating data from code is a GoodThingTM. FlowerData is all you can know about Flower. Flower receives FlowerData it can operate on (state). But both are distinct entities. DTO's are an "ashamed acknowledgement" of the fact, as all data can exist without behavior but not the other way around.
Did you ever read the classic Yourdon & Constantine's "Software Engineering"? He covers this issue, making it a point to avoid at all costs "pathological coupling".
I didn't, but I do know that Yourdon & Constantine coined many of the terms that we now use to describe software, "Coupling" as an idea to describe software was invented by Constantine I believe.
I'm glad you're doing this video. I've been a programmer for almost 25 years and I just heard about Coupling and Cohesion a few months ago. It's so much better and simpler than S.O.L.I.D. principles that everyone raves about.
De-Coupling, Strangler-Pattern, Microservice... is this just innuendo of some smart ass or do we have architectural patterns in social relationships or should I stop projecting?
Haha sure. Amdahl's law for parallel computation costs applies to anything you wanna process in parallel. That's why the team size typically doesn't scale well.
Actually if systems are connected using a database, there's a simple way to decouple them - using views. If a dependency changes its schema, you can recreate the view with a new query underneath.
At least APIs were mentioned 😀IOC is also an extremely useful principle when it comes to coding, absolutely ... while the video is a bit more "abstract" in that it points out at how many different levels coupling really exists and that it is not an anti pattern by itself. I found it very useful to raise the awareness of that. Just today I was part of a tech discussion where not everyone agreed on using some more in-depth features of a database technology for solving a certain type of problem because there was an assumption that the storage backend might change in the future (development coupling), while this is very unlikely. In that project there should be a REST service which will use that database technology and will of course have to be tightly coupled to it, using its features from "behind" the API. The technology comes with built-in features which are provided to deal with certain types of problems which naturally come with using a database. Sometimes tight coupling is a good thing. To avoid coupling when actually useful can create worse solutions or none at all. Sorry, included all of that while typing 😅 Inversion of Control, yes, love it too!
FREE 'How To Evolve Your Software Architecture' Guide: How to work in ways that keep stuff easy to change which gives you the freedom to make mistakes and experiment and how to work in small steps that allow you to determine their fit for your present understanding of the problem... continuously. All explained in this FREE compact guide. Download HERE ➡ www.subscribepage.com/evolve-your-architecture
This is good advice. Especially where the emphasis is on identifying areas where tight coupling is called for. I've seen projects fall to excessive cross talk and tragedy of the commons due to an irrational fear of any coupling whatsoever. The good part is that tight coupling is typically obvious compared to the much more subtle work of maintaining proper loose coupling. Loose coupling requires good discipline, and the ability to wear many hats within a system in order to understand zones of ownership and concern, and formalizing hand off between systems and domains. Fear of coupling at the start inevitably leads to shortcuts later on, with do-everything systems trouncing service-level tables in databases, internal members or state, or otherwise deep intertwined logic from a lack of formal exchange mechanisms that selective tight coupling helps illuminate.
I create modules within each main system object. This permits me to await for another module to load, and all relevant code and public methods are defined here.
Since then I've been able to rapidly develop large systems. I've been programming for 19 years and it's completely revolutionised my development.
The best definition of coupling I've come across is that if you have two code elements A and B they are coupled if a change in either forces a change to be made to the other. A and B can then said to be coupled with respect to that particular change.
You've got to do a video on entropy next time. I'd like to hear your take on cohesion and proper use of words from a DDD standpoint.
Words and language skills are kind of underestimated in software. They're really powerful in my opinion.
Thank you so much for this clear communication
This is nothing short of brillant, extremely important and widely under appriciated
Great vid. Your REST API example serves as a sort of materialization of design by contract, which is very OK in my book. It also falls into Allan Kay's "message passing" view which, again, is very OK as far as I'm concerned. As far as the contract and the message is properly documented both sides can go on their merry way and do whatever they have to do on their side. And you can extend it without breaking it by simply adding more endpoints (or versions of). And if you think of it as simply a "boundary between components", you can extend the concept to anything.
IMHO, this is where "classic OOP" does a great disservice by not saying that separating data from code is a GoodThingTM. FlowerData is all you can know about Flower. Flower receives FlowerData it can operate on (state). But both are distinct entities. DTO's are an "ashamed acknowledgement" of the fact, as all data can exist without behavior but not the other way around.
Did you ever read the classic Yourdon & Constantine's "Software Engineering"? He covers this issue, making it a point to avoid at all costs "pathological coupling".
I didn't, but I do know that Yourdon & Constantine coined many of the terms that we now use to describe software, "Coupling" as an idea to describe software was invented by Constantine I believe.
I'm glad you're doing this video. I've been a programmer for almost 25 years and I just heard about Coupling and Cohesion a few months ago. It's so much better and simpler than S.O.L.I.D. principles that everyone raves about.
They kinda go hand in hand, imo
The SOLID principles are aids towards loose coupling.
De-Coupling, Strangler-Pattern, Microservice... is this just innuendo of some smart ass or do we have architectural patterns in social relationships or should I stop projecting?
Yes, they are applicable in social relationships .
Haha sure. Amdahl's law for parallel computation costs applies to anything you wanna process in parallel. That's why the team size typically doesn't scale well.
Very informative 🧠
Actually if systems are connected using a database, there's a simple way to decouple them - using views. If a dependency changes its schema, you can recreate the view with a new query underneath.
I came here to hear the words dependency injection/inversion. Let's see if I get my wish...
Don't think I did. But it was a great video still
At least APIs were mentioned 😀IOC is also an extremely useful principle when it comes to coding, absolutely ... while the video is a bit more "abstract" in that it points out at how many different levels coupling really exists and that it is not an anti pattern by itself.
I found it very useful to raise the awareness of that. Just today I was part of a tech discussion where not everyone agreed on using some more in-depth features of a database technology for solving a certain type of problem because there was an assumption that the storage backend might change in the future (development coupling), while this is very unlikely.
In that project there should be a REST service which will use that database technology and will of course have to be tightly coupled to it, using its features from "behind" the API.
The technology comes with built-in features which are provided to deal with certain types of problems which naturally come with using a database. Sometimes tight coupling is a good thing. To avoid coupling when actually useful can create worse solutions or none at all.
Sorry, included all of that while typing 😅 Inversion of Control, yes, love it too!
3:35 Who doesn't love stock videos, let's take a look at what is happening around 7th line from the bottom of the screen 👀😆
It's FTSE all the way down