Comment by Geison Biazus on "Terraforming an Early Stage Startup (Part 1)"

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.

Hi Geison, so nice to hear from you. How are things in Germany?

Coupling is an interesting question. The reality, in my opinion, is that you are always coupled to something. The moment you call into another piece of code, you are essentially coupled into that code.

What you can do, however, is to choose what you are coupled to and control the degree of coupling you are to these things. Let me start defining the degree of coupling first.

What I mean by the degree of coupling is essentially the number of places in your code base that you reference a dependency directly. For example, you can use the Redis client directly all over your codebase, or you can create an abstraction layer, and reference this abstraction layer around instead. In the first case, you have a high degree of coupling with the Redis client. In the second case, you have a high degree of coupling with your abstraction.

In general, is better to have a high degree of coupling with things that you have control over or you better have a high degree of confidence that the thing you are depending on is really stable.

However, if your abstraction layer is poorly designed, you may end up with the worst of both worlds: having to spend time to create and maintain the abstraction layer while still being coupled to Redis, for example. This happens in particular through leaky abstractions:

joelonsoftware.com/2002/11/11/the-law-of-leaky-ab…

Now back into choosing what you're coupled to. The way I think about dependencies is just like marriage. Is this something that I'm confident that I'll be happy ever after, or should I have a prenup agreement (like an abstraction layer)? What if the dependency brings their family to live with us (the library dependencies)?

As I mentioned before, at the end of the day, it is unavoidable that you are going to be coupled into something. The important thing is to choose carefully with whom you will have a high degree of coupling.

Search Hashnode