What is coupling?

Today I watched a great presentation by Kent Beck from DDD europe 2020 about Continued Learning: The Beauty of Maintenance and he said something good about coupling, what it is and what it is not. The aim with this post is to summarize what he said about coupling. All pictures below is from that talk.

What's coupling?

As developers we always connect different services with each other. You have a frontend that calls a backend API, or you have a backend service that calls another backend service for example. In the latter case, one backend service has a relationship with another backend service.

Below is a picture of such a relationship (Kent calls it "element" during the talk, but an element can be anything here, a method/function or a service):

This begs the question - is A coupled to B? And the answer is no, it is not necessarily coupled.

So what is coupling?

Coupling is where A not only have a relationship with B, but whenever A changes, so must B. That's what coupling is about.

Is coupling bad?

If we take a look at this second picture again:

Is this bad? If one team is responsible for A and another team is responsible for B then yes this will be a problem. Why? Because team A will need to synchronize their backlogs with team B in order to get useful functionality released to customers. And we all know how well this synchronization goes in real life. Both teams are aligned and starts their work, but an urgent task shows up so team B must pause. Now team A is stuck and can't release their new feature.

So is coupling really bad?

If your company has 100 services and 2 of them are tighly coupled it might not be that big of a problem of course, so no need to create chaos because of that.

But if 30 of these services are tighly coupled and maintained by different teams you will have problems. One of the reasons why it is important to reduce coupling is to let the business evolve quickly. To envolve means to - when new business requirement shows up - be able to adapt your services accordingly and release it. Too much coupling greatly slows that process down.

Summary

Coupling has a cost associated with it and that is the cost of maintenance. Reduce coupling and your business can (most likely) evolve a bit quicker. Have high coupling and most features will be slow to develop. Developing new business features will take time. So it's worth to first spend some time and think about where your coupling is most painful and have a plan to reduce that coupling.