Balancing Coupling in Software Design

Why a Book on Coupling?

Sheen Brisals: Welcome to the GOTO Book Club. My name is Sheen Brisals. I'm a technology consultant, author, and a speaker. Last year, I was on this show speaking about my book, "Serverless Development on AWS." Today, I have the pleasure of sitting on the opposite side speaking to a popular author.

Vlad Khononov is going to talk about his new book on coupling. I say new book because Vlad is already a popular author because he has written one of the most popular books on domain-driven design, "Learning Domain-Driven Design." So it's my pleasure and privilege to speak to Vlad Khononov here on this show.

Hey, Vlad, welcome to the show.

Vlad Khononov: Hey, Sheen. Thanks so much. It's an honor being here.

Sheen Brisals: Why don't you take over and start introducing yourself to everyone?

Vlad Khononov: That's the hardest question to answer. So I guess I consider myself a software engineer. Whatever title I'm having at a job, whether it's a software engineer, an architect, or whatever, it all boils down to software engineering. That's what I love doing.

Now, the thing that I'm most proud of is the one that you have already mentioned. And that's the... no, actually two things. The "Learning Domain-Driven Design" book and the new one, "Balancing Coupling in Software Design." Beyond that, I'm speaking at conferences and I try to blog, but it's been a bit dry lately on my blog.

Sheen Brisals: You've been in the industry for so many years, engineer, author, speaker, writer, all sorts of activities. And coupling is a topic that is very common, but also very old, as old as some of the mountains out there. So let's hear from you why you took this topic at this point in time in the sort of evolution of engineering.

Vlad Khononov: Coupling and cohesion, these two terms are here forever, I think. And I remember hearing them for the first time. It was at a meetup here, a local meetup called Software Craftsmanship Tel Aviv. I don't remember what year it was. It was around 2006 or 2007. And somebody was doing a presentation and they were talking about coupling and cohesion. Now, I kind of understood what coupling is from that presentation, but cohesion was a bit of an enigma for me. So I kept it there at the back of my mind for quite a few years.

Then one day at the company I was working at, we decided to do a microservices-based project, an architecture that is based on the microservices style. And it failed miserably. It was such a failure in all regards. You take all those things that microservices architecture is supposed to give you and what we got was the complete opposite. So I was trying to understand what was going on, why this microservices thing works for others, but it didn't work for us, even though we were trying to do what people were talking about at conferences, podcasts, books, whatever. We tried to do it, got the opposite results.

So I started researching microservices. It started there, but it led me to software design principles. And then I found the answers I was looking for in a very old book on Structured Design, a book from the '70s. And the chapter that I was particularly interested in was called Coupling. And that moment changed the way I'm thinking about software design. And then I started investing more and more time in researching this topic of coupling. And as I gained more and more information, I started to adapt it to make it easier to work with. And the end result is this book, "Balancing Coupling in Software Design".

Recommended talk: Serverless Development on AWS • Sheen Brisals, Luke Hedger & Khawaja Shams • GOTO 2024

Coupling in Modern Software Architecture

Sheen Brisals: You touched on two things, which was kind of leading to my next question. So you went back to the '70s when the book was written and also you touched upon microservices. That's more like recent times. So if I time travel back to the '80s, '90s, basically '90s when I was initially doing development, it was so easy to look at coupling because everything, most of the things were homegrown. We developed applications, components, easy to relate coupling within and between the components. But now if you take microservices, you mentioned, say cloud, for example, cloud services, there are many services and so many SaaS providers on the platform. So when we build applications these days, we are consuming all these sorts of different applications or services and integrating interfacing with everything all over the world. How do you see the concepts you explain in the book relate to the newer times as you found the olden days how coupling was talked about?

Vlad Khononov: The funny thing is if you go back not to '90s, not to '80s, but '70s, even end of '60s, and you read that book that I mentioned, "Structured Design," the funny thing is that the problems that the authors are attempting to address by introducing that methodology, structure design, are so similar to issues we are fighting with today. Even though the technological stack was massively different, the tools they had were nowhere near what we have today. And of course, the problems they were solving with software. I don't know if it won't be justified to say that they were simpler, but let's say that the solution stack was definitely more compact. Let's say that they had fewer options.

So the problems that we as software engineers are facing are quite similar if you look through the years. But we managed to find ourselves in worlds of pain and problems, nevertheless. It doesn't matter what the solution stack we are working with, we can find how to shoot ourselves in the foot with it. And it usually has to do something with coupling.

One of the motives of my book, "Balancing Coupling in Software Design," one of the things I want to say is that no matter what level of abstraction you are working with, if you are working with a distributed system, microservices, cloud infrastructure, etc., all the way down to instructions in assembly code, software engineering revolves around the same design principles, and they apply to all those levels of abstraction.

So on the one hand, yeah, it's sort of bad news that our solution stack today is so wide. But the good news is that I believe if you understand those design principles that have something to do with coupling, then it will make your life so much easier, no matter what level of abstraction you're working on.

Sheen Brisals: Exactly. I like that because I read the book and I was smiling at so many parts of the book as I was reading through. Because I spend a lot of time in the event-driven architecture, serverless cloud these days. And we always hear about coupling and mostly we hear about decoupling or someone will say, oh no, it's not decoupling, it's loose coupling. So those are the terms we are familiar with.

But one thing you make clear in your book is that no matter where things are, I think you took an analogy of planets, right? So even though planets are millions of miles apart, there is still coupling in the sense of gravitational force, right? So that thought kept me thinking because that is a nice way of seeing coupling and also making the modern engineers who are not familiar with the term or the terminology better. So that takes home the message, right? So that's a really good point to portray coupling in the modern application landscape.

So in terms of coupling, one of the things that I found really useful in the book is that you added measurements to several aspects of coupling. You talk a lot about the strength or the distance, so on and so forth. But have you applied these principles with your clients or in your day-to-day work and things like that?

Vlad Khononov: In order to have that confidence to write a book about it, I have to test everything I say in my own work. So everything you read about in the book was battle-tested, battle-proven, and it was changed because of the results on the battlefield. Because if I go back in time to 2018-19, around that time, that's when I started applying that model of balanced coupling and integration strength. And it took a number of iterations to get where we are today.

Even if I look at that point of time when I started working on the book, when I said, okay, this is it, this is something that I want to write about, even after that point, it changed quite significantly. For example, the integration strength model, originally it had five levels. For example, my plan was to use structured designs, module coupling, and to make it easier to use nowadays because that model was based on terms from programming languages that are, luckily, we're not using today anymore. So if you would use that model today, it would definitely make you sound smart, but no one is going to understand what you mean. So I wanted to make it as approachable as possible.

Now, originally there were five levels. For example, there was functional coupling and logical coupling. I remember one of the reviewers, it was Vaughn Vernon, he said that logical coupling makes no sense because it describes something that is probably terrible, but you are using the word logical, but it's not logical to do that. Cool. Let's incorporate that feedback. So logical coupling went away and became a part of functional coupling, one of its degrees.

Initially, there was a level called implementation coupling, which is a dependency on implementation details. And then we had an hour-long conversation with Vaughn Vernon because he didn't like that name implementation coupling. It took us over an hour... sorry, it took him over an hour because he came up with that word intrusive coupling, which captures the intent so beautifully, so elegantly. It's like the perfect word for that level of integration strength, intrusive coupling. So I guess that was the moment where that model was... it took its shape and form that you can find in the book today. Going back to your question, yeah, everything was tested in my work, but it took a lot of time to find that shape and form for that model that in my opinion is the most approachable and the easiest to work with.

Recommended talk: I Made Everything Loosely Coupled. Does My App Fall Apart? • Gregor Hohpe • GOTO 2022

Applying Coupling Principles to Estimation

Sheen Brisals: The reason I was asking that question is because I wanted to understand not from you, how others adopted or understood what you are kind of proposing with these sort of calculations. Because working in the industry with engineers, one of the hardest things I noticed was problem decomposition. Many engineers struggle to even make a start, how to decompose a problem. And then you need to give cues and tips and tricks. So then they understand, oh, this is how they... I can use this tool or that tool, etc., etc.

If you go back in those days, when we used to do estimations, we used to look at function point analysis that used to be popular. Over the years, Agile brought in story points and various sorts of doing estimations. So now with what you are detailing in the book and what you are educating engineers in the book is a way of looking at complexity and assessing the complexity. So how that can now bring more educated estimation into application development, for example. How do you see that slowly evolving in the minds of engineers and among the teams?

Vlad Khononov: That's a great question. Actually, it makes me a bit angry, angry at myself that I didn't think about it when I was writing the book. Great question.

Unfortunately, I haven't used this model as means for optimizing estimations, but I can totally see how it can be useful for. Because the higher the level of uncertainty, the more uncertain your estimations are going to be. So the more safe buffer you have to add. So I think it can be very useful, but unfortunately, I haven't tried that.

Sheen Brisals: Right. Okay. That's something I think will be really beneficial for engineers rather than just... because, you know, all applications these days interact with third parties or different domains and departments, so on and so forth. So it's really important that given that you place all the different constraints and things available, I think they will become more important, useful to have that sort of understanding and knowledge built into them. Yeah.

Complexity, Modularity, and the Future of Software Design

Sheen Brisals: Another aspect, in addition to coupling, of course, you need to touch upon is the complexity. You talked a lot about the complexity in the book. Actually, I'm giving a talk at a conference later this month, and the talk is about embracing complexity in serverless. So I will be using references from your book, but something I noticed as I was reading through is, like, terminology that I think again originated from the '70s. It's about the local complexity and the global complexity. And then you apply the coupling aspects on top. Why did you brought that into this book? Just to start with.

Vlad Khononov: We didn't plan it, but again, it's about the same book, "Structured Design," that I mentioned twice already. So now it's a third time. These two terms are from that book, "Structured Design" by Glenford Myers.

Back when I was researching my failed microservices project, suddenly I stumbled upon those two terms and suddenly everything made so much sense that with that failed microservices project, we optimized local complexity, the complexity of the source code of each service. It was really simple. It was really micro, like really short. But on the other hand, the global complexity of the overarching system was quite high. It skyrocketed.

So at that moment, why on earth aren't we using these two terms nowadays? So ever since I've been using those terms all the time, and of course I had to include them in the book because that's the purpose of... I needed them to discuss how we usually apply, how we optimize coupling, and how in some cases we can optimize coupling on one level of abstraction, but again, shoot ourselves in the foot on another level of abstraction. And without these two terms, it's really hard to spot those cases. So yeah, same book, "Structured Design."

Sheen Brisals: Exactly. And the reason I brought that in is because those simple concepts originated many decades ago. Because these days, whenever I talk about event-driven architecture or serverless applications, I also talk about complexity in two different ways, like accumulated complexity versus distributed complexity. And also, for example, accumulated is probably a monolith where everything is local, where distributed is like you have a distributed set of applications where things are going all over the place. So then as I was reading, I thought, oh, I can relate the meaning of the local versus global complexity of the '70s to how we now develop and deploy and operate applications on the cloud. So again, simple concepts, but different meanings and interpretations, but still valuable to this day. So that's the reason I brought that one in.

The Failed Microservices Project

Sheen Brisals: Another aspect I wanted to touch, you spoke a few times about the failed microservices project. Now, modularity is something you discuss in the book, and there is a reason for it. Before we get there, can you just, for everyone's benefit, explain why that project failed?

Vlad Khononov: Because we did a lot of stupid things. Again, let's put it in context. The context is the early days of the microservices hype train. And we were learning from podcasts, from conference talks by people from those big companies embracing this architectural style. And I would say that we failed because of the decomposition principle that we applied. And that decomposition principle focused on the local complexity of each service. So we went from monolithic solutions, which were quite big, and it would take some time to grasp what is implemented there. And we went towards those services, which are micro. So we put that micro around the code that is written in each service.

Now, as a result, what happened was that we deployed that system to production. Initially, it looked awesome, but then every change we had to make, it touched on multiple services. They had to be deployed simultaneously. Otherwise, errors, collisions, mistakes, bugs, however you want to call them. So that was the issue. We focused on optimizing local complexity, we increased the global complexity, and we couldn't evolve that system because of that. So that was the reason.

Sheen Brisals: I think that's the mistake many teams make because they think that microservices are independently deployable, single purpose, so on and so forth. But when it comes to coupling or dependency, they often miss the basic best practice patterns. And the reason I brought microservices into it is because you talked about modularity. And the fact I liked about modularity, the way you pictured it, is like modularity, when we build modular systems in a proper way, it avoids or eliminates the accidental complexity, because then you have a better pattern for extendability, so on and so forth.

The essential complexity is kind of encapsulated within the sort of the module. That's a cool thing. I think it takes time for some engineers to understand these concepts, but it's something important to get across, especially while architecting or designing applications. So in terms of microservices and modularity and complexity and coupling, do you see that we probably need a different pattern or a different sort of way of doing things these days, especially with the cloud in the mix?

Vlad Khononov: That's an interesting question. On the one hand, I want to say that it doesn't matter because again, my point of view is that once you understand the basic design principles around managing coupling and balancing its dimensions, then it doesn't matter. If you're developing a monolith, it's going to be a modular monolith. If you're developing a distributed system, then those microservices are going to be modular. They're going to be modules.

However, on the other hand, there was an old WCF book. Sorry, I don't remember the name of the author and the title of the book. I just remembered that it was about the WCF framework by Microsoft. And in that book, there was a historical perspective about managing coupling that throughout the years as our industry became more and more mature, we were adding more and more levels of abstraction to manage coupling, to fight coupling. And I think those were the words that were used in that book. So when that book was written, it was in the days of SOA, service-oriented architecture. Then microservices approach kind of refined how we want to approach that distributed architectural style. And if history teaches us anything, then probably there are going to be some other level of abstraction that will be introduced maybe tomorrow, maybe a year from now or 10 years from now. Sometime in the future, there has to be another level of abstraction, I guess. Based on that historical perspective, it's going to happen.

Recommended talk: Software Architectures, Team Topologies & Complexity Science • James Lewis • GOTO 2023

Bringing Creativity to Technical Writing

Sheen Brisals: The event-driven architecture of these days, right? There's plenty of interactions or events flowing all over the place. We are kind of developing a network of systems with all events going here and there. More and more the awareness of these principles will benefit teams when they come to looking at architecting those solutions.

I'm just going to take a deviation from talking about technology. Everyone knows you as an author, Vlad Khononov, but I want to talk to you about the poett Vlad. Because usually when I write a blog post or when I write a book, I start with a phrase or a famous quote. I usually search all over the internet to find the best-fit quote. You in this book took it a different way. You just came up with a simple poem for each chapter. How does this happen? And what's the background to your poetry skills?

Vlad Khononov: That's quite a long story, to be honest.

Sheen Brisals: Happy to hear.

Vlad Khononov:First of all, it's no secret that this book was published three years late. So I started working on it quite a while ago. It was around 2021. Back then I was trying to force myself to write something, but then, you know, writer's block and suddenly other things are way more interesting than writing the book than actually working. But you try to find the connection between the things that you're distracting yourself with. And if you can find some connection to the book, then suddenly you feel that, okay, I'm still working on the book.

So long story short, OpenAI. Back then they were not really known. And then they released their text completion API. It was way before ChatGPT. You would give a string and it will complete it. You'll say, okay, and I said, okay, let's play with it. Let's ask this person to write a book for me. Didn't work. Of course.When I gave up on that, I said, okay, so the point of the book is to say that coupling is not something that you have to fight, but something that you can manage. Write a poem about it. And then it came up with those, those first two lines were brilliant. They were "strong or loose, we live in dread of the coupling monster under the bed." And I'm like, this is fantastic. And the rest of the poem was terrible. The rest was... I don't want to recall that. So it was terrible.

I was so fascinated, but fascinated by those two lines. Matt, I said, okay, cool. Let's get back to the real work. And I kept those two lines in the back of my head for some time. And then I finished the first draft, I think the second draft, and by that time they already had ChatGPT. And I think it was GPT3 or 2.5. I don't remember. One of them came out. It was new and groundbreaking at the time. I said, okay, let's try to write... ask it to write a poem for each chapter.

I said for the first chapter, these are the first two lines, "strong or loose, we live in dread of the coupling monster under the bed." The rest you're right. Make it funny, make it about the contents of the chapter. But the goal was to make it funny. And some of them were funny. Some of them were okay. But most of them, I remember showing them to Nick Tune and he said, look, this is lame. So most of them were lame. So at that moment I kind of decided, okay, I'll just delete them. They're not that good. They're not really funny, most of them. I cannot leave only one or two poems.

Then again, I got more and more feedback and I started seeing that this book is heavy. This is not what people are expecting from me because they had read "Learning Domain-Driven Design", where I took that methodology and I gave them 20% of the methodology that in my experience gives them 80% of the value. It was defined as a white belt book. And in the end, they said to get the black belt, you have to read Vaughn Vernon's red book, Eric Evans's blue book, and then you will get your black belt. That's where you get the whole understanding of the methodology.

With this one, I couldn't do it because I cannot point to another book. I cannot point to that book from the '70s because it's really hard to read nowadays. So at that point, I understood that my book is becoming heavy, and I like way too much material. So first of all, there is a lot of stuff that I had to remove in the editing process. Then I decided that I will go back to those poems again. This time, my goal is not to make something funny, but to make those poems serve purpose. The purpose was to give an overview of each chapter. So when the reader begins a new chapter, they have those four lines, which are kind of easy to read, easy to understand. And suddenly they have the understanding of the overarching theme of that chapter, what that chapter aims to communicate. And for me, it makes it easier to read the whole chapter.

Now, ChatGPT still cannot write a poem as I wanted them to be. So what I had to do is to go to a grocery store, get a pack of Red Bulls, lots of Red Bulls, and I spent lots and lots of time writing poems with ChatGPT. I would say that it's a collaboration. It's 50-50. I had to write 50% of each and every poem in the book. The other 50% is from ChatGPT. I had to invest so much time in writing them because yes, I'm not a poet and I'm not a writer, but being a poet is so much more difficult than being a writer, I guess.

Sheen Brisals: I really like that you brought that variation into each chapter. I was going to read a poem, but then I thought, okay, I won't reveal the secret. So I let listeners buy the book, read those poems in every chapter. And it's so cool. 

Vlad Khononov: What you can read, by the way. I would love to hear which one you like the most, for example.

Sheen Brisals: No, I had it, but I don't have the book with me, the physical copy. So I was reading the online O'Reilly platform. I think it'll probably become the trend rather than adding somebody's quotes or phrases. Now people will think differently. Okay. Why don't we kind of become a variation, bring in a variation or something?

Vlad Khononov: In the end, there is this bird of covering, which is kind of another overview of the whole book, but in a way that I hope is going to be easier to remember.

Sheen Brisals: So why don't you tell the listeners where they can find your book?

Vlad Khononov: The book is available on Amazon and the regular bookstores. The one that Pearson works with is called informit.com. There you can buy the PDF version. On Amazon, you can buy a Kindle version. Of course, both of them, you can buy a physical copy. Yeah, and it's also available on O'Reilly online learning platform. If you are a subscriber, then probably you had the chance to read one of the first drafts that was published there. And if you're one of those people that read it, then I'm sorry. I'm truly sorry for what you had to go through.

From Complexity to Modularity

Sheen Brisals:  So O'Reilly platform, online learning platform is great because they bring in books from different publishers, not just O'Reilly. So it's so convenient to read everything. So before we close, any message you want to convey in terms of coupling or complexity to the listeners?

Vlad Khononov: I guess it all boils down to going away from complexity to modularity. And we haven't really touched on concrete materials from the book in this podcast. So I will summarize complexity as when you want to do something and you don't know what the outcome of that action is going to be. That's complexity.

Now, why it happens is because of the cognitive load of the way that system is designed, you simply cannot fathom all the interactions between the components of that system. The opposite of that is modularity. I would say in two words, no, sorry, not two words, two sentences. The goal of modularity is when you want to make a change, then first thing is you know what you have to change. You can easily locate that component that is in charge of that functionality you have to modify. And the second thing is once you make the change, you know exactly what's going to happen. So that's why modularity is the opposite of complexity. One, complexity is a result of increased cognitive load. Modularity, on the other hand, decreases the cognitive load. Makes it easier to understand that system. How to go from one to the other? Coupling. It all boils down to coupling. How are those components in the system integrated? What is the knowledge that is being exchanged between them? And what is the physical position of the components in the system? That's the book in a nutshell.

Sheen Brisals: Thank you. I think it is very well summarized. So I think we are coming to the end of the show. So thank you so much, Vlad. It's absolutely a pleasure and privilege for me to speak to you for this show here. And I'm sure the concepts, the coupling, and the complexities, and how to measure them will benefit many engineers of this generation. Importantly, it will bring smiles to many faces as it did to me. So thank you again so much. Thank you for being on the show. Thank you.

Vlad Khononov: Thank you so much. And it's a pleasure being here. I loved the questions and yeah, it's an honor to hear that feedback from you. Thank you so much.