Hi Marcelo, it's nice to hear from you too. Things are good around here, despite the lockdown since December. I agree with everything you said, and to decrease the degree of coupling and facilitate the management of dependencies is why we have SOLID, Design Patterns, and other architectural patterns. My point is how often I see projects that simply marry with a database or a framework making everything hard to test and hard to change, and how important it is to have guidance and alignment since the beginning of the project to disseminate a culture of code quality.

Great article Marcelo! I have been part of many teams in my career and all of them suffer from the same problem, coupling. The team is composed of very talented engineers that give their best to build the software in the best way they know and in the quickest way possible. What they don't do is think about the future and think that the solution they are building at the moment will need to change for a variety of reasons. So the final product is always coupled. And with many types of coupling: Library coupling: "Let's use this library with 22 stars on GitHub, we can deliver this feature a lot faster". Until you realize that this library also depends on other n libraries and will not be updated making you stuck with your current versions of even unrelated libraries. Infrastructure coupling: This happens especially when the team decides to go microservices to "reduce" the coupling but in the end, services are totally coupled to databases, pub subs, and many other services from the cloud provider. In a way that when you change the schema o something in one service, it breaks other services that depend on that schema. Coupling is what makes everything hard to change and I think that the only way to mitigate that is by having guidance and alignment since the beginning from experienced people so this become part of the culture and values of the whole engineering team and the existing team members can pass it to the new members that arrive.