Coupling Is The Biggest Challenge In Software Engineering

coupling in software is often seen as the enemy tight coupling bad loose coupling good but it's not really that simple so what really do we mean by coupling and what does it take to manage it to our [Music] advantage hi I'm Da Farley of continuous delivery if you haven't been here before then please do hit subscribe and if you enjoy the content today hit like as well a few years ago I was speaking at a conference alongside my friend Michael nyard he gave a terrific talk on coupling that I have often quoted since much of this video is based on Mike's model for coupling in it he presented a thoughtful well-reasoned exploration of all of the different kinds of coupling that we tend to face in software Michael identified five different types of coupling that we should consider operational coupling a consumer can't run without the provider so if your system can't provide its service if the database is up and running then it's operationally coupled to the database then there's developmental coupling changes in producer and consumer must be coordinated between different parts of the system if the release of your service or app depends on the release of a new version of a platform or library then they are developmentally coupled apps are often developmentally coupled with each other VI shared plat platform or Library code too I can't release my application until a new feature is added to the platform but the platform team is busy working on features for your application and you won't be able to release your your version until my features are done too then there's semantic coupling components change together because of shared Concepts if your shopping cart and your order processing system need to change together because they both shared the concept and model of how money is represented and they're semantically coupled then there's functional coupling things change together because of shared responsibility when you have several different parts of your code that address similar problems in different ways they're functionally coupled I once worked on a large project that implemented seven different approaches to storing things in the same relational database because they were developed by different teams all trying to solve the same problem and finally incidental coupling things has changed together for no good reason at all two systems in a data center stop working because a fan breaks and the server that they both run on crashes because it's too hot let's pause there for a moment and say thank you to our sponsors we're very grateful to our sponsors for their support we're sponsored by equal experts transic and semaphore all of these companies offer products and services that are well aligned with the topics that we discuss here every week so if you're looking for ex excellence in continuous delivery and software engineering then please do check out their links in the description below at its root the management of coupling is I think one of the deepest fundamentals of design skill in this is what really differentiates great software design from average or poor design to a large degree and as I've already said this is not just a matter of loose coupling is good and strong coupling is bad we need to select the appropriate levels of coupling to fit the task at hand the decision of what level of coupling makes sense and is appropriate is a function of many many things so this is by no means a simple task but I think that this is why to a larger degree the choice of coupling is so Central to the effectiveness of our designs and ultimately of the software that we build I argue in my book modern software engineering that the ability to change our software is the defining characteristic of its quality sure you you may need other things but if you can't change the code the only way to get those other things is by getting everything perfectly right first time and good luck with that coupling is one of the key attributes that defines how easy it is for us to be able to change our software fortunately Beyond just recognizing it after the fact there are a variety of things that we can do to help us to deal with coupling appropriately before it gets in our way one is to take a more evolutionary approach to software architecture there's a link to my new how-to guide on evolutionary architecture in the comments below niggards model is a valuable tool too in helping us to surface this level of design thinking nygard's model is not one that simply categorizes the coupling in a situation into one of these five groups it's more complicated than that coupling is multifaceted any particular solution will exhibit several of these coupling categories to some degree in his excellent talk which I do strongly recommend to you he demonstrates this idea with several good examples one of which is the difference in coupling between a sql-based conversation with a data store a rest based conversation and an event driven style B message-based conversation coupling is also about more than only the technicalities the famous conways law that states that organizations that Design Systems are constrain trained to produce designs which are copies of the communication structures of the organization by Melvin e Conway is really a statement about coupling too our technical choices related to coupling have a big impact on sensible organizational structures and our choice of organizational coupling can limit our ability to make progress at all or liberate creativity and and productive technical work so we can see from Michael's database example that because there's a very strong operational and developmental coupling between a database and an application that interacts with it this is a fairly poor place to introduce an organizational barrier at least for most kinds of system however even this isn't quite that simple though because there is nothing wrong with strong coupling if the coupling is stable in this example SQL doesn't change much so that aspect of the operational coupling is really pretty table but the bit that's probably not is the schema so what about the schema any application that talks to a SQL database is coupled both via SQL but also via the the schema that's more application specific so the design of that might be changing then developmental coupling between the team maintaining the database and the team's writing apps against it is a big problem so separating the app and the database teams here is not a very efficient organizational design when the schema is often changing so maybe a better bet then would be to decouple the teams by adopting a rest API instead these are still both strongly coupled in terms of operation and development but if the team looking after the data store is also responsible for producing an API that abstracts access to the database they are now in a place to own the changes end to end within their own code this is a much more stable position to be in as long as they don't break the API they can change anything they like in fact this is the real purpose of an API to provide a kind of protection an insulation layer this gives additional wiggle room to decouple API consumers from API producers the big advantage of the last example in this sequence the event-driven approach is that operational coupling is now very weak indeed and developmental coupling is weak this comes at the expense though of semantic coupling in this model we need to maintain shared message semantics but with the advantage that we can translate at the points of creation and consumption of the messages which means that now we've gained a lot of extra wiggle room to reduce the chances of introducing breaking changes between the two parts of the system I think we all often think of ideas like these in terms of coupling but other tools at our dis osal may be a little less obvious one of the big advantages for example of continuous integration is that it allows teams to work on much more strongly coupled software by continuously validating that our small changes to even very tightly coupled code doesn't break things this means that we can now use continuous integration as a tool to defend those more coupled interactions when we need them we may want tighter coupling for a variety of reasons when we don't know enough yet to be confident of all of our abstractions for example say at the start of a design when we expect to evolve later once our API stabilize into a microservice design or maybe when we are building very high performance systems and so we don't want to avoid too many translation steps between services but once again we still expect our apis to evolve I start any new system with continuous integration as a result of this it provides the most effective most stable starting Point even if I expect my system to be more decoupled in future I do this because it takes a while to learn what abstractions work best and that is best done through a process of experimentation and refinement continuous integration then protects me while I'm learning how best to manage the coupling in my system types is in in languages is another valuable tool that allows us to know exactly where and to what extent change is needed between more coupled pieces of code all of this is complex enough but for people teams and organizational structures this is an even more complicated problem the classic response to scaling development is to divide work into specialisms business architecture UI backend testing operations and so on this builds a development organization as a series of coupled silos that every feature must pass through this is a lot of people whose work is now dependent on that of everyone else progress is difficult sometimes even impossible I can't write code until I have a ux design I can't test the code until the dev devs tell me that it's Dev complete and so on worse I can't improve the design because the plan that coordinates the work of all of these teams and people is based on a current assumed coupled design one way of thinking about what Agile development based on small autonomous teams is really all about is that it's about Distributing decision making decoupling for teams and organizations great development is very significantly about reducing the scale of change small teams matter because they are more independent more decoupled smaller changes matter because each change is less entangled with the others again more decoupled modular systems matter because they decouple systems through seams of abstraction between the modules cohesion and separation of concerns matter because they help our modules to remain modular by keeping the stuff that is related within a module and the stuff that's unrelated in other modules abstraction matters because it allows us to hide information for each part of the code to keep secrets from every other part of the code so one take on my five principles to manage complexity in software from my book is that they're all fundamentally about managing coupling coupling is a crucial aspect of developing complex software or software at scale actually I'd argue that even simple systems are complex enough to pay attention to coupling in your designs if you don't already do that you'll thank me later if you try it essentially we have two tools at our disposal the architecture and design of our software and the speed of feedback on the safety of our changes we can cope with more coupled systems as long as we have fast enough feedback we can cope with slow feedback as long as our systems are sufficiently decoupled the middle ground is where the disasters happen strongly coupled systems with poor feedback I Define poor feedback on the releasability of my changes as being more than a day if your work relies on the work of other people outside your team before you can make progress your development system would certainly work better if it was more Loosely coupled or placed in a shared repo and evaluated all together managing coupling is the foundation to scaling software and to scaling software development too autonomous teams who are responsible for the software that they create work best to scale because they are decoupled so pay attention to coupling thank you very much for watching and if you enjoy our stuff here on the continuous delivery Channel please do consider supporting our work by joining our patreon community there are lots of benefits and as ever I'd like to thank our patrons for their ongoing support [Music]

Channel: Continuous Delivery

Views: 21,404

Keywords: coupling, software coupling, coupling vs cohesion, coupling vs cohesion in software engineering, cohesion, cohesion in software engineering, software engineering, software engineering challenges, computer science, programming, what is coupling in software engineering, coupling in java, coupling in python, coupling in programming, dave farley, continuous delivery, software development, modern software engineering

Id: plMttQWztRM

Length: 13min 32sec (812 seconds)

Published: Wed May 15 2024