Coupling Is The Biggest Challenge In Software Engineering

Coupling in

software

is often seen as the enemy. If you haven't been here before, please subscribe and if you like today's content, like it too. A few years ago I was speaking at a conference with my friend Michael Nyard, he gave an excellent talk on

coupling

that I have often cited. Since much of this video is based on Mike's

coupling

model, he presented a thoughtful and well-reasoned exploration of all the different types of coupling we tend to face in

software

. Michael identified five different types of coupling that we should consider operational coupling. a consumer cannot run without the provider, so if your system cannot provide its service, if the database is up and running, then it is operationally coupled to the database, then there are development coupling changes in the producer and the consumer that must coordinate between different parts of the system.

If the release of your service or application depends on the release of a new version of a platform or library, then they are developmentally coupled. Applications are often developmentally coupled with each other. Shared Platform VI or library code as well. I can't publish my application. until a new feature is added to the platform, but the platform team is busy working on features for their app and won't be able to release their version until my features are also ready, then there are semantic coupling components that change together due to shared concepts. If your shopping cart and your order processing system need to change together because they both share the concept and model of how money is represented and are semantically coupled, then there is 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 are 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 eventually incidentally coupled things changed for no good reason. The two systems in a data center stop working because a fan breaks and the server they are both running on crashes because it gets too hot. Let's pause for a moment and thank our sponsors. We are very grateful to our sponsors for their support. We are sponsored by equal experts at Transic and Semaphore. All of these companies offer products and services that are well aligned with the topics we discuss here each week, so if you're looking for an ex. excellence in continuous delivery and software

engineering

, then check out their links in the description below at its root, coupling management is.

I think one of the deepest foundations of design skill is what really differentiates great software design from average or poor design. largely and as I 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 suit the task at hand, deciding which level of coupling Feeling and being appropriate is a function of many things, so this is by no means a simple task, but I think it is why, to a greater extent, the choice of coupling is so central to the effectiveness of our designs. and, ultimately, of the software that In my book Modern Software Engineering I argue that the ability to change our software is the defining characteristic of its quality.

Sure you may need other things, but if you can't change the code, the only way to get those other things is to do everything perfectly right the first time and good luck with that docking is one of the key attributes that defines how easy it is. It's for us to be able to change our software, fortunately. Beyond simply recognizing it after the fact, there are a variety of things we can do to help us deal with coupling properly before it gets in our way 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.

The niggards model is also a valuable tool. To help us bring to light this level of design thinking, Nygard's model is not one that simply categorizes coupling in a situation into one of these five groups; More complicated is that that coupling is multifaceted, any particular solution will exhibit several of these categories of coupling to some extent. In his excellent talk, which I highly recommend, he demonstrates this idea with several good examples, one of which is the difference in coupling between a SQL-based conversation with a data warehouse, a rest-based conversation, and a event-driven style B messages. Conversation coupling is also about more than technicalities: Conways' famous law that states that organizations whose design systems are capable of producing designs that are copies of Melvin and Conway's organizational communication structures is in actually a statement about the coupling also of our technical aspects.

Choices related to coupling have a huge impact on sound organizational structures and our choice of organizational coupling can limit our ability to progress or unleash creativity and productive technical work, as we can see in the database example. from Michael that because there is a very strong operational relationship. and the development coupling between a database and an application that interacts with it, this is a pretty poor place to introduce an organizational barrier at least for most types of systems; however even this is not that simple 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 operational coupling is really a pretty table but what you probably not be the scheme, so what about the scheme?

Any application that communicates with a SQL database is coupled through both. SQL, but also through schema which is more application specific, so the design could be changing, so development coupling between the team that maintains the database and the team that writes applications is a big problem, so separating the application and database computers here is not. a very efficient organizational design when the scheme changes frequently, so perhaps a better bet would be to decouple the teams by adopting a rest API, both are still tightly coupled in terms of operation and development, but if the team takes care of the warehouse The data manager is also responsible for producing an API that abstracts access to the database.

You are now in a place to own the changes from start to finish within your own code. This is a much more stable position as long as they don't break the API. they can change whatever they want, in fact this is the true purpose of an API to provide a type of protection and isolation layer that gives additional leeway to decouple API consumers from API producers. The big advantage of the last example in this event sequence. The driven approach is that operational coupling is now very weak and development coupling is weak. This comes at the expense of semantic coupling.

In this model we need to maintain the semantics of shared messages, but with the advantage that we can translate at the points of creation and consumption. of messages, which means that we have now gained a lot of additional leeway to reduce the chances of introducing major 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 the same time. our removal 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 tightly coupled software by continually validating that our small changes, even to very tightly coupled code, don't break things.

This means 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 yet know enough to be sure of all our abstractions, for example. say at the beginning of a design, when we hope to evolve later once our API stabilizes in a microservice design or perhaps when we are building very high performance systems, so we don't want to avoid too many translation steps between services, but once again I still hope our APIs evolve. I start any new system with continuous integration, as a result of this it provides the most effective and stable starting point, even if I expect my system to be more decoupled in the future.

I do this because it takes a while to learn. which abstractions work best and what is best done through a process of experimentation and refinement, continuous integration then protects me while I learn how to best manage coupling across my system types in languages ​​is another valuable tool that allows us to know exactly where and to what extent changes are needed between more pieces of code coupled together this is all quite complex, but for teams of people and organizational structures this is an even more complicated problem the classic answer to scalable development is to divide the work into specialties architecture enterprise UI backend testing operations, etc., this builds a development organization as a series of coupled silos that each feature must pass through.

There are many people whose work now depends on everyone else's. 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 developers tell me it's complete and worse, I can't improve the design because the plan that coordinates the work of all these teams and people is based on a current assumed coupled design , one way to think about what agile development based on small autonomous teams is really about is that it is about Distributing the decoupling of decision making 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. More decoupled modular systems matter because they decouple systems through seams of abstraction between modules. Cohesion and separation of concerns matter because they help our modules remain modular. Keeping things that are related within a module and things that are unrelated in other modules, abstraction is important because it allows us to hide information for each part of the code to keep secrets from all other parts of the code, so one adopts my five principles for Managing Complexity in Software from my book is that they are all fundamentally about managing coupling.

Coupling is a crucial aspect of developing complex software or software at scale. Actually, I would argue that even simple systems are complex enough to pay attention to coupling in their designs. If you haven't already, you'll thank me later if you try. Basically, we have two tools at our disposal: the architecture and design of our software and the speed of feedback on the security of our changes. We can deal with them more closely. 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 disasters occur. tightly coupled systems with poor feedback.

I define bad feedback about being able to release my changes as more than a day, if your work depends on the work of other people outside your team before it can progress, your development system would certainly work better if it were more loosely coupled or placed in a shared repository and evaluated all together. Coupling management is the foundation for scaling software and scaling software development as well. Autonomous teams that are responsible for the software they create work better at scale because they are decoupled, so pay attention to coupling. Thank you very much for watching and if you enjoy our material here on the continuous delivery channel.

Please consider supporting our work by joining our Patreon community. There are many benefits and, as always, I would like to thank our sponsors for their continued support.