Actionable Insights into Loosely Coupled Architectures
Audience Perspectives: Interest and Engagement Levels
In the last week, I have asked my audience on LinkedIn about their current state of working with loosely coupled architectures. One of the most important things to mention upfront is that this is a highly contextual topic, which became clear to me during the conversations and feedback on 1:1 calls.
So, for context, we will talk primarily about web applications since this covers most of my audience.
Who Engages with Discussions on Loose Coupling
Interestingly, apart from trunk-based development, this topic garners both curiosity and caution. Following multiple discussions, it's become clear to me that many developers are keenly interested in the subject but are approaching it from a learning perspective. Most of the substantive written feedback I've received has come primarily from seasoned seniors, architects, or team leads.
✅ I will take this as a learning before the stream and following articles to include everyone willing to understand and advance on this topic.
The Understanding of Loose Coupling
As expected, the level of confidence with loose coupling varies. There was very sophisticated feedback, as well as hesitance to really join the discussion. Around 20-25% of the responses were about the “Challenge to understand the concept.”–Which aligns with the high interest and lower engagement than usual. I would count this percentage even higher due to the hesitation I mentioned in the preface.
With
1 together, we will tackle this in the upcoming stream today, and there will be a follow-up article with an “In-Depth” conclusion about the “Why” regarding loose coupling.Important to note here is the feedback of Marcel Hageman2, in which he describes this as a team challenge. This is a very important aspect since we implement a single architecture with a team of many developers.
I voted for "Understanding the concept" because it's usually an entire team (or multiple teams) that need to grasp the concept and how "loose" you actually want things.
It's a huge gradient, not just between black & white, but all other colors (including the invisible ones).
It probably mostly depends on the team(s) (skills, willingness, guidance), project(s) (POC vs. business critical), and business needs.
Marcel Hageman
The Challenges with Loose Coupling
Throughout all discussions and polls, two particular challenges stood out.
Dependency management with around 36%
Communication of components with 40%
The percentage I got from a poll reflects the written responses very well. And it’s important to note here that the responses are with a clear majority of seasoned seniors again. Junior levels don’t seem to participate much on this topic.
Interestingly, I would have suggested seeing “Testing” more as a challenge since I read a lot about how loosely coupled architectures like Microservices are hard to test. In contrast, testing isn’t much of an issue when things are separated and decoupled.
👉 More about that topic in the follow-up article after the stream.
What about usage?
About 79% of the audience responded they were using it happily, and, interestingly, none were using it “unhappily.”
16% are interested in going for decoupling, which is a very good sign, in my opinion.
👉 Note that we will talk about the “Why” in today’s Engineering Culture stream, which might hopefully help even more developers to understand the benefits.
What is the primary benefit?
This was the third question we asked the audience, and we clearly saw that Maintainability was the main benefit.
Maintainability 48%
Flexibility 33%
Scalability 15%
Easier to test 4%
27 votes
An interesting comment was provided by Jonathan Hall3, who stated that maintainability covers them all. That’s true when we see it as an overarching quality or non-functional requirement. This is likely why maintainability was mentioned most, next to flexibility in most other discussions.
I feel like maintainability covers all the others
Jonathan Hall
Regarding Flexibility, I received very insightful feedback and an example by Glenn Anderson4 about how decoupling adds to the capability to run A/B tests for features.5
One obvious one is multiple implementations of a feature. This could be used, for example, for A/B testing or being able to deploy a development version for QA, but still keep shipping the existing one to production.
Glen Anderson
Join us live on LinkedIn.
We will discuss this topic, the current findings, and the “Why” with
. Looking forward to having you in the audience to discuss this topic with us! 🤝
Agenda for the Live Stream
This week, we made the agenda using your help and Adrian’s polls. Thank you so much for the input! 🤝
Risk and stagnation caused by tight coupling
Stop the productivity bleed-out on a web-based monolith
Are microservices enough?
Q&A, live discussion throughout the 90 minutes. Don't be shy!
https://www.linkedin.com/in/deniscahuk/
https://www.linkedin.com/in/marcelhageman/
https://www.linkedin.com/in/jhallio/
https://www.linkedin.com/in/glenn-anderson-450720/
https://www.linkedin.com/feed/update/urn:li:ugcPost:7121753769607864320?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7121753769607864320%2C7121804351727116288%29&replyUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7121753769607864320%2C7122075971880448000%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287121804351727116288%2Curn%3Ali%3AugcPost%3A7121753769607864320%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287122075971880448000%2Curn%3Ali%3AugcPost%3A7121753769607864320%29