Coupling Is The Biggest Challenge In Software Engineering
Вставка
- Опубліковано 14 тра 2024
- Coupling is more complicated than it sounds, in software many people would argue that loosely coupled systems are better, but most software doesn’t look like that.
Most software tends to err on the side of being too strongly coupled, in the sense that a change in one place forces changes in another, this is a huge problem in software development and software engineering that impacts everything from how we organise teams and scale development to how we design systems and how we write individual lines of code. Yet, we don’t often think about coupling explicitly. This is beyond the specifics of Java, Python or other programming languages, but firmly in the realms of the broader topics of software design.
In this episode Dave Farley author of best-selling books on software “Continuous Delivery” and “Modern Software Engineering” explores the the ideas, impact and application of coupling to software, and to organisational design. He explains with some examples "the Nygard Model of Coupling" which identifies 5 different types of coupling that we need to consider to build great software.
-
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 are explained in this FREE compact guide. Download HERE ➡️ www.subscribepage.com/evolve-...
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! ➡️ bit.ly/ContinuousDeliveryPatreon
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3Uby9iA
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🔗 LINKS:
“Michael Nygards Presentation - Uncoupling” ➡️ • Uncoupling • Michael N...
-
BOOKS:
📖 "Release It!", Michael Nygard ➡️ amzn.to/38zrINu
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
Semaphore is a CI/CD platform that allows you to confidently and quickly ship quality code. Trusted by leading global engineering teams at Confluent, BetterUp, and Indeed, Semaphore sets new benchmarks in technological productivity and excellence. Find out more ➡️ bit.ly/CDSemaphore
#softwareengineer #developer - Наука та технологія
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.
Thank you so much for this clear communication
This is nothing short of brillant, extremely important and widely under appriciated
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.
Very informative 🧠
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.
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.
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.
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.
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.
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 👀😆
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!
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.
It's FTSE all the way down