1 00:00:00,040 --> 00:00:04,640 Coupling can take your system either towards complexity or 2 00:00:04,640 --> 00:00:09,440 towards modularity. Coupling as inherent part of 3 00:00:09,440 --> 00:00:11,560 system design. Not something that is 4 00:00:11,560 --> 00:00:15,760 necessarily good or necessarily evil, but something that is 5 00:00:15,760 --> 00:00:17,360 needed. We need coupling. 6 00:00:17,720 --> 00:00:20,520 It's like a glue that holds system together. 7 00:00:20,840 --> 00:00:24,840 When people are talking about coupling, or rather decoupling, 8 00:00:25,200 --> 00:00:28,400 they mean let's take something big and break it apart into 9 00:00:28,400 --> 00:00:31,760 those tiny parts. Let's take a monolith and break 10 00:00:31,760 --> 00:00:36,360 it into micro services. However, if you're not following 11 00:00:36,560 --> 00:00:40,120 a proper decomposition criteria for drawing the boundaries of 12 00:00:40,120 --> 00:00:44,040 those resultant smaller components, you will end up with 13 00:00:44,040 --> 00:00:47,320 sharing lots of knowledge. As a result, you will end up 14 00:00:47,320 --> 00:00:51,840 with lots of cascading changes and as a result your system is 15 00:00:51,840 --> 00:00:57,160 going to be full of complexity. A modular system is a set of, 16 00:00:57,600 --> 00:01:02,520 let's say, modular components, but working not only towards the 17 00:01:02,520 --> 00:01:06,560 goal of that system today, but it is also designed in such a 18 00:01:06,560 --> 00:01:10,960 way that we'll be able to support goals that will be 19 00:01:10,960 --> 00:01:27,280 defined in the future. Hello, guys, I'm very happy to 20 00:01:27,280 --> 00:01:29,840 bring back another repeat guest to the Technical General 21 00:01:29,840 --> 00:01:32,240 Podcast. Today we have Vladik Kononov. 22 00:01:32,560 --> 00:01:34,960 So flat, really looking forward for this conversation. 23 00:01:34,960 --> 00:01:37,040 I still remember our first conversation, right? 24 00:01:37,120 --> 00:01:40,360 It was probably two years ago. Your episode is still within, 25 00:01:40,360 --> 00:01:43,240 you know, top ten. And I'm really glad to speak to 26 00:01:43,240 --> 00:01:46,640 you for your new upcoming book, Balancing Coupling and Software 27 00:01:46,640 --> 00:01:48,440 Design. So welcome to the show. 28 00:01:49,120 --> 00:01:52,280 Hey, Henry, thank you so much for having me again. 29 00:01:53,080 --> 00:01:55,760 And wow, time flies. Two years. 30 00:01:56,240 --> 00:01:58,280 Yeah. And I remember two years ago we 31 00:01:58,280 --> 00:02:02,600 were talking and I said that the coupling book is going to be 32 00:02:02,600 --> 00:02:04,720 finished soon. And here we are two years later. 33 00:02:06,360 --> 00:02:09,039 Yeah. So that I think it's been quite 34 00:02:09,039 --> 00:02:10,919 a while, right. So maybe in the beginning you 35 00:02:10,919 --> 00:02:14,320 can share apart from this book, anything else that you did 36 00:02:14,400 --> 00:02:16,240 probably interesting for you to share with us? 37 00:02:17,000 --> 00:02:23,480 So I'm mainly known by my work in the domain of DDD Domain 38 00:02:23,480 --> 00:02:27,400 Driven Design, and that's primarily the Learning Domain 39 00:02:27,400 --> 00:02:32,600 Driven Design book and the Cardboard Domain Driven design 40 00:02:32,600 --> 00:02:36,600 and people who are on Twitter, maybe they will be able to find 41 00:02:36,600 --> 00:02:41,680 out what that means. Right now, in last three years, 42 00:02:42,080 --> 00:02:45,600 I've been working very hard to finish the book on Coupling. 43 00:02:46,000 --> 00:02:50,200 Hands down, that's the hardest project I ever worked on. 44 00:02:50,200 --> 00:02:54,200 And I can't believe I'm saying this, but it looks like it's 45 00:02:54,240 --> 00:02:56,200 almost done. Right. 46 00:02:56,680 --> 00:02:57,840 Yeah. So in preparation of this 47 00:02:57,840 --> 00:03:00,160 conversation, I actually had a chance to read the book. 48 00:03:00,480 --> 00:03:02,720 I think I would say almost, you know, end to end, cover to 49 00:03:02,720 --> 00:03:06,400 cover, although it hasn't completed right on O'Reilly in 50 00:03:06,400 --> 00:03:09,360 the beginning, I was actually quite interested to actually 51 00:03:09,360 --> 00:03:12,680 figure out what exactly can you talk about coupling right? 52 00:03:12,680 --> 00:03:16,280 So it seems like almost everyone in the UNI learned about this 53 00:03:16,280 --> 00:03:18,520 coupling, right? But probably only a little bit, 54 00:03:18,520 --> 00:03:20,800 right? Like OK, coupling, cohesion, 55 00:03:20,840 --> 00:03:23,320 object oriented encapsulation and things like that. 56 00:03:23,560 --> 00:03:25,440 But you actually covered it in one book. 57 00:03:25,680 --> 00:03:28,680 And after I read it, it's actually very, very insightful. 58 00:03:28,960 --> 00:03:32,280 So let's try to engage a conversation about coupling 59 00:03:32,280 --> 00:03:34,440 today. So maybe in the first thing, 60 00:03:34,440 --> 00:03:35,920 right, we all know about coupling. 61 00:03:35,920 --> 00:03:37,680 Maybe we learn it in the university. 62 00:03:37,880 --> 00:03:41,600 What else that you are trying to explain actually by writing this 63 00:03:41,600 --> 00:03:44,840 book? Yeah, so coupling, I remember 64 00:03:44,840 --> 00:03:49,560 when the idea for this book came up and I was talking to my 65 00:03:49,560 --> 00:03:54,800 friends about it and one of them said coupling, like, OK, so 66 00:03:54,800 --> 00:03:59,720 coupling is bad and do you need like really 300 pages to say 67 00:03:59,720 --> 00:04:04,320 that that is bad? But as they say, the devil is in 68 00:04:04,320 --> 00:04:08,120 the details. So it happens quite often that 69 00:04:08,440 --> 00:04:11,680 we're using certain terms without fully understanding 70 00:04:11,680 --> 00:04:13,720 them. Like we have that gut feeling 71 00:04:13,840 --> 00:04:17,399 about something. So we are using that in our 72 00:04:17,399 --> 00:04:21,600 day-to-day language. However, we are not able to 73 00:04:21,600 --> 00:04:25,080 clearly describe what that something means. 74 00:04:25,520 --> 00:04:29,400 And that's something for me was coupling and cohesion for many, 75 00:04:29,400 --> 00:04:32,760 many years. I remember when I attended the 76 00:04:32,760 --> 00:04:36,280 first ever meet up, I attended, it was about coupling and 77 00:04:36,280 --> 00:04:39,920 cohesion. And yeah, I came out with this 78 00:04:39,920 --> 00:04:43,440 feeling, that gut feeling level. I understand what that means, 79 00:04:43,440 --> 00:04:47,560 but how can I explain what coupling is? 80 00:04:47,560 --> 00:04:49,320 Why is it bad? What is cohesion? 81 00:04:49,320 --> 00:04:53,920 Why is that good? So that's why I wanted to write 82 00:04:53,920 --> 00:04:59,040 this book and share my findings, my research on this topics. 83 00:04:59,040 --> 00:05:03,080 And if you're going to read the book, you'll see that although 84 00:05:03,080 --> 00:05:06,960 it's called balancing coupling and software design, it's main 85 00:05:06,960 --> 00:05:10,080 topic is complexity and modularity. 86 00:05:10,520 --> 00:05:14,560 I want to show what complexity is exactly in software design 87 00:05:14,560 --> 00:05:18,680 because again, that's another thing that we understand on the 88 00:05:18,680 --> 00:05:23,400 gut feelings level, but it's challenging to describe and it's 89 00:05:23,440 --> 00:05:26,840 even worse for a modularity. Like modularity, OK, they 90 00:05:26,840 --> 00:05:32,640 started talking about it in 60s, seventies, 80s, and today we all 91 00:05:32,640 --> 00:05:36,720 know that that's the goal we should strive towards. 92 00:05:36,720 --> 00:05:42,080 But what is modularity exactly? Like how can you put a number on 93 00:05:42,080 --> 00:05:44,360 a design? How can you evaluate whether 94 00:05:44,360 --> 00:05:49,560 it's modular or not? So that was my goal, to show how 95 00:05:49,800 --> 00:05:54,280 these two things are actually, or rather two sides of the same 96 00:05:54,280 --> 00:05:56,840 coin. And that coin is coupling. 97 00:05:57,160 --> 00:06:01,800 Coupling can take your system either towards complexity or 98 00:06:01,800 --> 00:06:06,480 towards modularity. And yeah, for that I had to 99 00:06:06,480 --> 00:06:10,280 write almost 300 pages. Right. 100 00:06:10,800 --> 00:06:15,280 So I think maybe let's try first of all to define the terms what 101 00:06:15,280 --> 00:06:17,720 is coupling, right? Because I think people know 102 00:06:17,720 --> 00:06:19,920 about low coupling, high cohesion, right? 103 00:06:19,920 --> 00:06:22,640 It's always like the terms that you always use, right? 104 00:06:22,680 --> 00:06:25,240 Good code means like low coupling, high cohesion. 105 00:06:25,480 --> 00:06:27,680 Maybe people associate coupling with just, you know, maybe 106 00:06:27,680 --> 00:06:30,320 functions or classes, design and things like that. 107 00:06:30,560 --> 00:06:34,120 But in your book, it is actually beyond just code level, right? 108 00:06:34,440 --> 00:06:37,920 It can even go up to organization level or different 109 00:06:37,920 --> 00:06:40,120 kind of services, right? Maybe let's start with the 110 00:06:40,120 --> 00:06:41,960 definition 1st. In your book what is the 111 00:06:41,960 --> 00:06:44,000 definition of coupling? Yeah. 112 00:06:44,000 --> 00:06:46,920 So let's say we're working on a system. 113 00:06:47,400 --> 00:06:51,640 A system is a number of components that are working 114 00:06:51,640 --> 00:06:56,960 together to achieve a goal. That goal is the reason why that 115 00:06:56,960 --> 00:07:00,000 system exists. Now, in order for those 116 00:07:00,000 --> 00:07:03,240 components to work together, they need to be connected, 117 00:07:03,240 --> 00:07:05,640 right? Because they cannot be fully 118 00:07:05,640 --> 00:07:08,840 independent of each other. That will be just a collection 119 00:07:08,840 --> 00:07:10,320 of components. That's it. 120 00:07:10,840 --> 00:07:16,360 But to make the value of that system higher than the sum of 121 00:07:16,360 --> 00:07:18,080 its parts, we need to connect them. 122 00:07:18,680 --> 00:07:20,840 And those connections are basically coupling. 123 00:07:21,360 --> 00:07:25,080 If you go to the dictionary and look up that word coupling, 124 00:07:25,280 --> 00:07:30,160 well, you'll see that initially what it means is not manolith, 125 00:07:30,160 --> 00:07:32,280 not big bowl of, but it means connection. 126 00:07:32,760 --> 00:07:35,120 If two things are coupled, they're connected. 127 00:07:35,600 --> 00:07:40,000 So I will ask you for the rest of our discussion, at least for 128 00:07:40,000 --> 00:07:43,200 the next 4051 hour. I don't know how long we're 129 00:07:43,200 --> 00:07:47,000 going to talk, but for the rest of this discussion, let's treat 130 00:07:47,000 --> 00:07:50,200 coupling as inherent part of system design. 131 00:07:50,400 --> 00:07:53,400 Not something that is necessarily good or necessarily 132 00:07:53,400 --> 00:07:56,120 evil, but something that is needed. 133 00:07:56,120 --> 00:07:59,440 We need coupling. It's like a glue that holds 134 00:07:59,440 --> 00:08:01,320 system together. We need it. 135 00:08:01,800 --> 00:08:05,920 However, how we're designing those interactions, how we're 136 00:08:05,920 --> 00:08:09,400 designing those connections between the components, that's 137 00:08:09,400 --> 00:08:13,280 where it gets interesting. That's where that coupling can 138 00:08:13,280 --> 00:08:16,520 take us, either towards comlexity or towards modularity. 139 00:08:17,280 --> 00:08:19,080 Right. So I think it's interesting that 140 00:08:19,080 --> 00:08:21,200 you mentioned about connectedness, right? 141 00:08:21,320 --> 00:08:23,760 It doesn't mean that when you have coupling, it's actually 142 00:08:23,760 --> 00:08:25,680 bad, right? Because coupling is necessary 143 00:08:25,680 --> 00:08:27,760 whenever you build software design because that's how 144 00:08:27,760 --> 00:08:31,000 components actually work in collaboration with each other, 145 00:08:31,000 --> 00:08:32,320 right? And you mentioned about 146 00:08:32,320 --> 00:08:35,480 connectedness in your book in terms of there are two things 147 00:08:35,480 --> 00:08:38,520 that probably are related when you talk about coupling. 148 00:08:38,520 --> 00:08:41,760 The 1st is about shared life cycle and the other one is about 149 00:08:41,760 --> 00:08:45,040 shared knowledge. I think having an understanding 150 00:08:45,040 --> 00:08:48,040 of these two is really critical. Before we move on to the next 151 00:08:48,040 --> 00:08:50,320 section, maybe you can talk a little bit more about this 152 00:08:50,320 --> 00:08:52,280 shared life cycle and shared knowledge. 153 00:08:52,960 --> 00:08:55,680 Yeah, of course. So first of all, let's assume we 154 00:08:55,680 --> 00:08:57,840 have two components in the system. 155 00:08:58,280 --> 00:09:02,920 Now I'm purposefully using these abstract terms components in the 156 00:09:02,920 --> 00:09:04,520 system. I'm not telling what these 157 00:09:04,520 --> 00:09:07,400 components are. They can be services, they can 158 00:09:07,400 --> 00:09:10,400 be objects, classes, even methods within a class. 159 00:09:10,800 --> 00:09:12,760 And same is true regarding this system. 160 00:09:12,760 --> 00:09:17,600 It can be a distributed system, it can be a module or an object, 161 00:09:18,120 --> 00:09:20,160 an object oriented codebase, doesn't matter. 162 00:09:20,640 --> 00:09:23,920 So let's say we have two coupled components. 163 00:09:24,440 --> 00:09:28,720 Now when we are saying that coupling is bad, what we usually 164 00:09:28,720 --> 00:09:34,120 imply is that we have to change those two components 165 00:09:34,400 --> 00:09:36,680 simultaneously. For example, you want to change 166 00:09:36,680 --> 00:09:41,080 one of them, but then you're forced to apply a corresponding 167 00:09:41,080 --> 00:09:42,720 change to the second component, right? 168 00:09:43,080 --> 00:09:45,240 And that connects their life cycles. 169 00:09:45,480 --> 00:09:48,640 They have to be evolved simultaneously. 170 00:09:49,160 --> 00:09:51,520 Now, is that something we are interested in? 171 00:09:51,640 --> 00:09:53,560 It depends. We'll talk about it a bit later, 172 00:09:53,560 --> 00:09:56,320 I assume. But right now, let's assume that 173 00:09:56,400 --> 00:10:00,800 coupling introduces that dependency in the life cycles of 174 00:10:00,800 --> 00:10:04,360 connected components. Now, propagating changes in 175 00:10:04,360 --> 00:10:08,160 almost all cases is not something that we want. 176 00:10:08,160 --> 00:10:12,880 We want to be able to modify each component individually. 177 00:10:13,280 --> 00:10:16,560 Once we introduce those connections between components. 178 00:10:16,960 --> 00:10:20,240 In order to work together, they have to share some knowledge 179 00:10:20,240 --> 00:10:24,560 about each other and the amount of knowledge they share. 180 00:10:24,920 --> 00:10:31,240 It actually dictates what is the amount of cascading changes that 181 00:10:31,320 --> 00:10:33,640 are going to follow because of that design. 182 00:10:34,080 --> 00:10:38,520 That knowledge can be as simple as a knowledge of integration 183 00:10:38,520 --> 00:10:41,080 interfaces. Let's say I have a module, so I 184 00:10:41,080 --> 00:10:44,040 define its public interface. You want to work with it, you 185 00:10:44,040 --> 00:10:47,520 have to know the details of its public interface. 186 00:10:47,800 --> 00:10:53,680 Or maybe, let's say you want to ignore that public interface and 187 00:10:53,800 --> 00:10:57,120 you want to use some other means of integration. 188 00:10:57,120 --> 00:11:00,160 Let's say you want to reach out to my database. 189 00:11:00,360 --> 00:11:03,600 In that case, maybe you want to, you will have to know the 190 00:11:03,600 --> 00:11:05,560 implementation details of my module. 191 00:11:05,560 --> 00:11:09,200 So that's the other extreme of knowledge that can be shared. 192 00:11:09,200 --> 00:11:12,400 And of course, if I'm sharing only the integration interface, 193 00:11:12,720 --> 00:11:15,960 then the amount of cascading changes that are going to follow 194 00:11:15,960 --> 00:11:19,240 is going to be dramatically lower than in the second case 195 00:11:19,240 --> 00:11:23,200 where you're coupling yourself to my implementation details. 196 00:11:23,680 --> 00:11:26,920 So overall, these are two properties that are very 197 00:11:26,920 --> 00:11:29,320 interrelated. The first one is how connected 198 00:11:29,320 --> 00:11:33,800 are the life cycles of those connected components, and the 199 00:11:33,800 --> 00:11:38,680 second one is what is the amount of knowledge that's been shared 200 00:11:38,680 --> 00:11:40,560 across the component's boundaries. 201 00:11:41,480 --> 00:11:43,640 Yeah, thank you for explaining this. 202 00:11:43,640 --> 00:11:46,320 I think it's such an insightful concept when I read it in the 203 00:11:46,320 --> 00:11:49,280 first few chapters, because maybe the life cycle is kind of 204 00:11:49,280 --> 00:11:51,840 like straightforward, right? Whenever you make changes, if 205 00:11:51,840 --> 00:11:54,400 you have to propagate into multiple places, right? 206 00:11:54,560 --> 00:11:57,240 It could even be services or multiple teams. 207 00:11:57,600 --> 00:12:00,040 That is actually pretty bad. And we know that it's actually 208 00:12:00,080 --> 00:12:01,800 tightly coupled, right when we do that. 209 00:12:02,160 --> 00:12:05,280 But actually the most important thing that I find really 210 00:12:05,280 --> 00:12:08,280 interesting is about the shared knowledge, because there are 211 00:12:08,480 --> 00:12:11,040 explicit knowledge that you share, maybe about business 212 00:12:11,040 --> 00:12:14,360 requirements or maybe even the interface or contract APIs, 213 00:12:14,360 --> 00:12:16,040 right, when you interact with APIs. 214 00:12:16,480 --> 00:12:18,920 But also there's implicit knowledge that probably is a bit 215 00:12:18,920 --> 00:12:21,920 tricky to identify. And that's why you find it 216 00:12:21,920 --> 00:12:25,600 difficult to explain the coupling by just looking at the 217 00:12:25,600 --> 00:12:27,280 code, right? Because it's such an implicit 218 00:12:27,280 --> 00:12:31,640 thing and let's try to actually analyze in terms of coupling and 219 00:12:31,640 --> 00:12:33,760 complexity, right? Because people associate 220 00:12:33,760 --> 00:12:35,920 coupling a lot with the complex code. 221 00:12:36,360 --> 00:12:39,960 So you try to explain it with Kinovin framework, right? 222 00:12:40,160 --> 00:12:43,320 So maybe a little bit of background, why is it such a 223 00:12:43,320 --> 00:12:46,560 relevant to talk about Kinofin when explaining this coupling 224 00:12:46,560 --> 00:12:48,400 and complexity? Yeah. 225 00:12:48,400 --> 00:12:53,680 So first of all, I want to go back to your first comment about 226 00:12:53,680 --> 00:12:56,360 the relationship between life cycle coupling and knowledge, 227 00:12:56,360 --> 00:12:59,080 because I think it's super important what you said here, 228 00:12:59,280 --> 00:13:03,240 because when people are talking about coupling or rather 229 00:13:03,280 --> 00:13:07,320 decoupling, they mean let's take something big and break it apart 230 00:13:07,320 --> 00:13:11,000 into those tiny parts. Let's take a monolith and break 231 00:13:11,000 --> 00:13:15,560 it into micro services. However, if you're not following 232 00:13:15,760 --> 00:13:19,320 a proper decomposition criteria for drawing the boundaries of 233 00:13:19,320 --> 00:13:23,280 those resultant smaller components, you will end up with 234 00:13:23,280 --> 00:13:26,520 sharing lots of knowledge. As a result, you will end up 235 00:13:26,520 --> 00:13:30,520 with lots of cascading changes. As a result, you're going to end 236 00:13:30,520 --> 00:13:33,520 up cursing that very day you started decomposing it. 237 00:13:34,080 --> 00:13:39,120 And as a result, your system is going to be full of complexity. 238 00:13:39,640 --> 00:13:44,200 Now, complexity is something that you know it when you see 239 00:13:44,200 --> 00:13:46,360 it. But again, we need something 240 00:13:46,360 --> 00:13:49,440 more precise, something that we can explain. 241 00:13:49,920 --> 00:13:53,240 So that's why I chose to use Kinemic Framework. 242 00:13:53,280 --> 00:13:57,440 I really like how this framework, originally it's a 243 00:13:57,520 --> 00:14:02,880 decision support framework. It provides with different, we 244 00:14:02,880 --> 00:14:05,040 are talking about software engineers, so let's say 245 00:14:05,040 --> 00:14:08,400 different scripts for making decisions and how to make 246 00:14:08,400 --> 00:14:10,240 decisions in different situations. 247 00:14:10,760 --> 00:14:17,440 And it categorizes those contacts into five domains, each 248 00:14:17,440 --> 00:14:21,360 one requiring unique approach to making decisions. 249 00:14:21,720 --> 00:14:25,880 If let's say you are working on a system and again we are 250 00:14:25,880 --> 00:14:30,240 software engineers, let's say we're working on code base and I 251 00:14:30,240 --> 00:14:33,920 want to make a change. If I know exactly what the 252 00:14:33,920 --> 00:14:38,160 effect of that change is going to be, then that code base is 253 00:14:38,160 --> 00:14:40,640 not complex, right? It's probably simple. 254 00:14:41,040 --> 00:14:45,400 That's why this domain, in kinetic terms is called a clear. 255 00:14:45,760 --> 00:14:47,960 It's something that is simple clear. 256 00:14:48,240 --> 00:14:50,840 If I'm making a change, I know what's going to happen. 257 00:14:51,280 --> 00:14:54,320 If, on the other hand, I am looking at the code base and I 258 00:14:54,320 --> 00:14:58,400 have no clue what's going on there, however, I can consult 259 00:14:58,400 --> 00:15:02,240 somebody, some external expert, and that expert will tell me 260 00:15:02,240 --> 00:15:05,680 exactly what's going to happen. Then again, it's not complexity. 261 00:15:06,080 --> 00:15:07,960 This time we have a complicated system. 262 00:15:08,600 --> 00:15:11,560 For example, let's say I am looking at a code base written 263 00:15:11,560 --> 00:15:17,840 in Go, or I don't know Scala. Even though I tried to learn 264 00:15:17,840 --> 00:15:21,280 these two languages, I would still prefer to call an external 265 00:15:21,280 --> 00:15:23,840 expert to help me out to understand what's going on 266 00:15:23,840 --> 00:15:27,240 there. So again, that's not a reason to 267 00:15:27,240 --> 00:15:29,840 call it complex. That's something that is 268 00:15:29,840 --> 00:15:32,760 complicated. And we arrived to the third 269 00:15:32,760 --> 00:15:35,040 domain, which is a complex domain. 270 00:15:35,440 --> 00:15:39,880 Here we have no idea what the effect of a change is going to 271 00:15:39,880 --> 00:15:42,640 be. Also there is no expert we can 272 00:15:42,640 --> 00:15:46,520 consult. So the only option we have is to 273 00:15:46,520 --> 00:15:49,880 conduct a safe experiment, which means to make a change and 274 00:15:49,880 --> 00:15:55,840 observe it's results and based on those results to try and 275 00:15:55,920 --> 00:15:59,400 understand it's impact. So that's complexity. 276 00:16:00,000 --> 00:16:04,280 Now in this domain, we assume that there is a connection 277 00:16:04,280 --> 00:16:08,080 between an action and it's outcome, A cause and effect. 278 00:16:08,560 --> 00:16:12,520 Now in the fourth domain, which is called chaos, there is no 279 00:16:12,520 --> 00:16:16,160 relationship between A cause and effect, the effects are random. 280 00:16:16,640 --> 00:16:22,600 Now, such things do happen in software of course, especially 281 00:16:22,600 --> 00:16:26,640 in production environments after deploying Fridays or on public 282 00:16:26,640 --> 00:16:30,400 holidays. However, this is something that 283 00:16:30,400 --> 00:16:34,320 is rather not related to our discussion of software design. 284 00:16:34,640 --> 00:16:39,080 It's more related towards the runtime of the system. 285 00:16:39,640 --> 00:16:43,120 But in software design, when we're changing the system, it 286 00:16:43,120 --> 00:16:47,880 should be somewhat deterministic one way or another. 287 00:16:48,200 --> 00:16:51,680 And finally, the 5th domain of Canavan, it's unknown. 288 00:16:51,720 --> 00:16:54,360 When you're looking at the domain, you have no idea where 289 00:16:54,360 --> 00:16:56,800 you are. And in this situation you may 290 00:16:56,800 --> 00:17:02,360 assume that it's clear, it's something simple, but as I say, 291 00:17:02,360 --> 00:17:05,079 devil is in the details. And when you get to details, 292 00:17:05,079 --> 00:17:09,119 it's only discovered that it's complex domain or chaotic domain 293 00:17:09,119 --> 00:17:11,839 or whatever. So these are the five domains. 294 00:17:12,280 --> 00:17:15,560 And I really like the way Dave Snowden, the author of this 295 00:17:15,560 --> 00:17:20,160 framework, defined complexity when the only way of identifying 296 00:17:20,359 --> 00:17:23,319 outcome of an action is conducting safe experiments. 297 00:17:24,000 --> 00:17:28,319 Unfortunately, that's something that is pretty frequent in 298 00:17:28,319 --> 00:17:30,800 software design when you're looking at the code base and you 299 00:17:30,800 --> 00:17:34,160 want to refactor. Well, if you know what's going 300 00:17:34,160 --> 00:17:37,800 to happen, great. Maybe it's complicated and that 301 00:17:38,160 --> 00:17:41,400 expert is the compiler. Maybe compiler can tell you 302 00:17:41,400 --> 00:17:44,760 what's going to happen or a colleague that build that code 303 00:17:44,760 --> 00:17:48,680 base in the 1st place. But in many cases, when we're 304 00:17:48,680 --> 00:17:52,760 working with legacy systems, brothel projects or big bowl of 305 00:17:52,760 --> 00:17:58,000 Muds, we make a change. And I had a friend I still 306 00:17:58,000 --> 00:18:02,520 remember that I was working at, It was actually my first, like 307 00:18:02,520 --> 00:18:05,280 real workplace. And that colleague of mine 308 00:18:05,280 --> 00:18:08,320 showed me, look, before doing something important, I have 309 00:18:08,320 --> 00:18:10,680 these stones. I place these stones on my 310 00:18:10,680 --> 00:18:14,280 keyboard for good luck. So once you need those stones 311 00:18:14,280 --> 00:18:16,360 for good luck, you're in complexity. 312 00:18:16,360 --> 00:18:20,960 And yeah, you need to find a way out of it one way or another. 313 00:18:21,760 --> 00:18:24,080 Right. I think that's a very relatable 314 00:18:24,080 --> 00:18:26,280 joke, right? And some people also like think 315 00:18:26,280 --> 00:18:27,920 of it like test in production, right? 316 00:18:27,920 --> 00:18:30,960 It you will only know once it hits production with the real 317 00:18:30,960 --> 00:18:33,520 traffic, real data and real user behaviors. 318 00:18:33,840 --> 00:18:37,000 So I think, yeah, when you find that kind of situation, probably 319 00:18:37,000 --> 00:18:38,840 it's more about complexity, right? 320 00:18:38,920 --> 00:18:42,240 It's not about complicated, it's not about something like chaotic 321 00:18:42,240 --> 00:18:44,440 as well, right. So I think this kind of 322 00:18:44,520 --> 00:18:47,760 framework really, really good to picture what kind of a domain 323 00:18:47,760 --> 00:18:50,480 you are dealing with. And thanks for pitching in about 324 00:18:50,480 --> 00:18:53,520 this splitting, because people normally when they deal with 325 00:18:53,520 --> 00:18:55,680 coupling, they will say, OK, I will just split more, you know, 326 00:18:55,680 --> 00:18:58,920 like micro surveys, for example, or create more classes, create 327 00:18:58,920 --> 00:19:01,280 more abstraction. The other thing about dealing 328 00:19:01,280 --> 00:19:03,720 with coupling for some people, right, they build more 329 00:19:03,720 --> 00:19:07,080 flexibility when you say coupled or it means like difficult to 330 00:19:07,080 --> 00:19:09,440 change. So people try to build more 331 00:19:09,600 --> 00:19:11,520 flexibility, degrees of freedom, right? 332 00:19:11,760 --> 00:19:15,080 In your book, you actually find that these two extremes actually 333 00:19:15,080 --> 00:19:19,440 is very dangerous and it might lead to complexity in terms of 334 00:19:19,440 --> 00:19:22,120 code, right? And you classify this sometimes 335 00:19:22,160 --> 00:19:25,440 as accidental complexity. The other one is essential 336 00:19:25,440 --> 00:19:28,240 complexity, right? So tell us more about these two 337 00:19:28,240 --> 00:19:30,920 different complexity as well, because I think it's really 338 00:19:31,080 --> 00:19:34,400 important for software engineer to understand essential and also 339 00:19:34,400 --> 00:19:37,400 accidental complexity. Yeah, of course. 340 00:19:37,560 --> 00:19:42,560 So let's say that you're working on a system for a non trivial 341 00:19:42,560 --> 00:19:45,240 business domain. Because come on, nowadays if if 342 00:19:45,240 --> 00:19:47,640 the business domain is trivial, JGPT is going to do it. 343 00:19:48,040 --> 00:19:51,640 So assuming that you are working on a non trivial business 344 00:19:51,760 --> 00:19:55,680 domain, there will be some complexity in it, complexity 345 00:19:55,680 --> 00:19:57,760 that is driven by its requirements. 346 00:19:57,840 --> 00:19:59,960 For example, let's say it's financial system. 347 00:20:00,360 --> 00:20:03,680 That domain is not simple or a medical system. 348 00:20:03,800 --> 00:20:08,320 Even worse, if there's something interesting that the system is 349 00:20:08,320 --> 00:20:10,640 doing, usually it involves some complexity. 350 00:20:10,880 --> 00:20:15,240 That's the reason the system is being built, in order to help 351 00:20:15,480 --> 00:20:19,040 its users. To encapsulate that complexity 352 00:20:19,040 --> 00:20:20,800 in the system to take care of it. 353 00:20:21,320 --> 00:20:24,680 So that's the essential complexity of that business 354 00:20:24,680 --> 00:20:26,560 domain of the problem you're solving. 355 00:20:27,000 --> 00:20:30,720 There is no way of avoiding it. If you avoid that essential 356 00:20:30,720 --> 00:20:33,280 complexity, then your system is not doing it's job. 357 00:20:33,680 --> 00:20:36,720 Why do I need it if it's not going to help me to take care of 358 00:20:36,720 --> 00:20:39,560 that complexity, right? We cannot avoid it. 359 00:20:39,720 --> 00:20:41,440 So we have to manage that complexity. 360 00:20:41,840 --> 00:20:44,800 How can we manage it? Well, we have plethora of tools 361 00:20:44,840 --> 00:20:47,480 from domain driven design to design patterns, whatever. 362 00:20:47,840 --> 00:20:50,600 We can talk in details about each one of them, but we'll need 363 00:20:50,600 --> 00:20:54,520 them 24 hours at least. So that's the essential 364 00:20:54,520 --> 00:20:55,880 complexity. Again, something that you 365 00:20:55,880 --> 00:20:58,920 manage. The accidental complexity on the 366 00:20:58,920 --> 00:21:03,120 other hand is something that you introduce, something that you 367 00:21:03,120 --> 00:21:07,280 introduce by not designing your system properly. 368 00:21:07,760 --> 00:21:13,080 And again, if we define complexity as that implicit 369 00:21:13,080 --> 00:21:18,080 relationship between an action and its outcome, then accidental 370 00:21:18,080 --> 00:21:22,600 complexity is designing a system in such a way that whoever is 371 00:21:22,600 --> 00:21:26,120 going to work on it next, or maybe even me tomorrow, won't 372 00:21:26,120 --> 00:21:30,200 have any clue if a line has been changed, what effect of that 373 00:21:30,200 --> 00:21:33,960 change is going to be on other components within the same 374 00:21:33,960 --> 00:21:36,480 system. Or maybe it's interactions with 375 00:21:36,520 --> 00:21:40,280 other systems which are even worse and even harder to predict 376 00:21:40,320 --> 00:21:42,880 than effects within my code base. 377 00:21:43,400 --> 00:21:48,960 Again, it's all matter of design of how you architect your system 378 00:21:48,960 --> 00:21:51,040 and how you design those interactions. 379 00:21:51,480 --> 00:21:54,960 Which means those connections, which means coupling between 380 00:21:54,960 --> 00:21:59,680 it's components, whether it's going to introduce that 381 00:21:59,920 --> 00:22:03,600 accidental complexity or on the other hand, it will help you to 382 00:22:03,600 --> 00:22:06,960 manage that essential comlexity. Right. 383 00:22:07,200 --> 00:22:10,400 So I think when we talk about complexity, Please remember in 384 00:22:10,400 --> 00:22:11,960 your mind, right? Are you talking about the 385 00:22:11,960 --> 00:22:15,080 essential complexity, which is actually the problems that 386 00:22:15,080 --> 00:22:16,560 you're trying to solve? Maybe it's the business 387 00:22:16,560 --> 00:22:19,360 requirements, maybe it's like a functionalities that you have to 388 00:22:19,360 --> 00:22:22,600 build an algorithm, right? Or are you actually dealing with 389 00:22:22,600 --> 00:22:25,640 accidental complexity things like you weren't aware you 390 00:22:25,640 --> 00:22:28,280 designed something and actually the impact is a little bit 391 00:22:28,280 --> 00:22:31,680 unpredictable, right? Maybe you expect one conflict 392 00:22:31,680 --> 00:22:34,520 change, but how come that you actually deal with so many 393 00:22:34,520 --> 00:22:36,680 changes, cascading changes in multiple places? 394 00:22:37,280 --> 00:22:40,480 So I think don't introduce too much accidental complexity and 395 00:22:40,480 --> 00:22:43,000 probably coupling is actually one of the root cause why 396 00:22:43,000 --> 00:22:44,720 accidental complexity can happen. 397 00:22:45,080 --> 00:22:48,320 So let's move on maybe from complexity to the other one, 398 00:22:48,320 --> 00:22:50,480 modularity. As you mentioned right when you 399 00:22:50,760 --> 00:22:53,440 write this book, you want to cover these two areas really 400 00:22:53,440 --> 00:22:56,320 important. So I think modularity also kind 401 00:22:56,320 --> 00:23:00,160 of like covered a lot right, in basic software design or you 402 00:23:00,160 --> 00:23:04,440 know, programming courses. But what is something different 403 00:23:04,440 --> 00:23:06,760 about modularity that you want to talk about in relation to 404 00:23:06,760 --> 00:23:08,240 coupling? Yeah. 405 00:23:08,240 --> 00:23:11,680 So first of all, to define modularity, what is it? 406 00:23:12,040 --> 00:23:15,520 If you look up that word in many places you will find the 407 00:23:15,640 --> 00:23:20,080 recursive definition of like a modular system is one that build 408 00:23:20,080 --> 00:23:23,800 of modular components. Thank you for that, that really 409 00:23:24,000 --> 00:23:26,800 really helps me. On a serious note, you may also 410 00:23:26,800 --> 00:23:31,960 find definition saying that a modular system is one that is 411 00:23:31,960 --> 00:23:34,920 built out of interchangeable components. 412 00:23:34,960 --> 00:23:40,240 A system that resembles Lego bricks that you can connect with 413 00:23:40,240 --> 00:23:42,240 each other and form something else. 414 00:23:42,640 --> 00:23:46,400 Now let's say you're working on a typical knowledge management 415 00:23:46,400 --> 00:23:49,600 system for a business. It doesn't resemble Lego bricks. 416 00:23:50,080 --> 00:23:52,360 I don't think so. Do you need interchangeable 417 00:23:52,360 --> 00:23:55,160 components? Maybe you will have to change 418 00:23:55,160 --> 00:23:58,920 the database one time because you will need to run your tests 419 00:23:58,960 --> 00:24:02,080 on in memory database, which is not going to be a real one. 420 00:24:02,080 --> 00:24:05,800 But that's it. That's probably the limit of our 421 00:24:05,800 --> 00:24:09,520 interchangeable components. Maybe you should encapsulate all 422 00:24:09,520 --> 00:24:12,880 the managed services of your cloud vendor so that you can 423 00:24:13,240 --> 00:24:17,960 migrate to another cloud vendor. Maybe it should, but trust me, 424 00:24:17,960 --> 00:24:20,680 those abstractions you're going to introduce are going to be 425 00:24:20,680 --> 00:24:23,840 leaky anyways, and that migration is not going to be as 426 00:24:23,840 --> 00:24:28,480 simple as people hope. So still doesn't mean that we 427 00:24:28,480 --> 00:24:30,240 don't need modularity. Now. 428 00:24:30,640 --> 00:24:35,000 We definitely need modularity. However, we also need to define 429 00:24:35,280 --> 00:24:38,120 what we mean by it. And here I want to go back to 430 00:24:38,120 --> 00:24:42,760 the definition of a system that I started with early on saying 431 00:24:42,760 --> 00:24:46,240 that a system is a set of components working towards a 432 00:24:46,240 --> 00:24:49,600 goal. A modular system is a set of, 433 00:24:50,040 --> 00:24:54,600 let's say modular components, but working not only towards 434 00:24:54,720 --> 00:24:59,120 it's goal, the goal of that system today, but it is also 435 00:24:59,120 --> 00:25:03,880 designed in such a way that we'll be able to support goals 436 00:25:04,160 --> 00:25:05,920 that will be defined in the future. 437 00:25:06,280 --> 00:25:08,960 Now to support goals that are going to be defined in the 438 00:25:08,960 --> 00:25:12,480 future doesn't mean that out-of-the-box it has to 439 00:25:12,480 --> 00:25:14,200 implement all possible use cases. 440 00:25:14,200 --> 00:25:16,680 No, of course not. And that's not possible. 441 00:25:17,160 --> 00:25:21,000 The design of that system should be able to withstand 442 00:25:21,280 --> 00:25:25,600 implementations of those future use cases, those future 443 00:25:25,600 --> 00:25:29,040 requirements. Now this begs the question, OK, 444 00:25:29,040 --> 00:25:32,040 so let's say I'm working on knowledge management system for 445 00:25:32,040 --> 00:25:36,360 a business in financial domain. It doesn't mean that my design 446 00:25:36,360 --> 00:25:41,840 has to support the option of that system turning into a 447 00:25:41,840 --> 00:25:43,880 driver for a printer in the future. 448 00:25:44,360 --> 00:25:48,200 Of course not. That's not a goal that you have 449 00:25:48,200 --> 00:25:51,040 to think about. So when thinking about 450 00:25:51,040 --> 00:25:55,560 modularity, we have to take into account future goals, but they 451 00:25:55,560 --> 00:25:59,000 have to be reasonable. How do we identify those 452 00:25:59,040 --> 00:26:02,560 reasonable changes? Well, that's another thing that 453 00:26:02,560 --> 00:26:08,000 makes our job so hard. So we have to think about those 454 00:26:08,040 --> 00:26:10,640 future changes. Which changes are going to be 455 00:26:10,640 --> 00:26:15,120 reasonable and which are not. Of course, the example I used of 456 00:26:15,120 --> 00:26:16,840 a printer driver is a simple one. 457 00:26:17,280 --> 00:26:20,040 But yeah, real life is a bit more complicated. 458 00:26:20,520 --> 00:26:25,360 So again, going back to the definition of modularity and 459 00:26:25,360 --> 00:26:30,520 modules and modular systems, the goal is to design a system in 460 00:26:30,520 --> 00:26:34,040 such a way so that it will support future requirements. 461 00:26:34,360 --> 00:26:40,280 Once it does, then we can say that those components it is 462 00:26:40,280 --> 00:26:42,560 composed of are actually modules. 463 00:26:43,080 --> 00:26:47,920 So that brings me into another problematic topic of modules 464 00:26:47,920 --> 00:26:51,000 versus components, because I define the system as a set of 465 00:26:51,000 --> 00:26:54,360 components and the modular system as a set of modules. 466 00:26:54,760 --> 00:26:58,120 Now if you look up on the Internet the difference between 467 00:26:58,200 --> 00:27:03,040 these two terms, you will see some problematic definitions. 468 00:27:03,440 --> 00:27:08,400 Some sources claim that modules are, let's say, logical 469 00:27:08,400 --> 00:27:11,960 boundaries, whereas components are physical boundaries. 470 00:27:12,400 --> 00:27:16,720 Now this thinking model can be useful in some contexts. 471 00:27:17,160 --> 00:27:22,040 However, if you go back to the origins when the term modularity 472 00:27:22,040 --> 00:27:26,680 was introduced to software engineering, you will see that 473 00:27:26,680 --> 00:27:30,360 back then they had three properties of a module. 474 00:27:30,360 --> 00:27:34,560 One of them was that it should encapsulate a behaviour, meaning 475 00:27:34,560 --> 00:27:38,200 that we have some behaviour that is encapsulated in one module 476 00:27:38,280 --> 00:27:40,400 instead of being spread across multiple modules. 477 00:27:40,840 --> 00:27:46,000 Second, it has to expose an interface through which other 478 00:27:46,000 --> 00:27:50,280 parts of the system can execute that functionality. 479 00:27:50,600 --> 00:27:55,080 And 3rd, it should have potential of being independently 480 00:27:55,080 --> 00:27:56,920 compiled. Only potential. 481 00:27:57,400 --> 00:28:02,760 It doesn't mean that whether you're compiling your module 482 00:28:03,040 --> 00:28:05,320 independently turns it into a component. 483 00:28:05,880 --> 00:28:10,760 No, it is still module. Again, that definition is, in my 484 00:28:10,760 --> 00:28:13,960 opinion, it's flexibility is very useful. 485 00:28:14,520 --> 00:28:16,440 Yeah. So the difference between 486 00:28:16,440 --> 00:28:19,360 components and modules, it's not about the type of boundaries, 487 00:28:19,360 --> 00:28:20,960 whether they're physical or logical. 488 00:28:20,960 --> 00:28:23,160 It's about encapsulating functionality. 489 00:28:23,240 --> 00:28:27,360 And that's something that is essential for managing the 490 00:28:27,360 --> 00:28:30,240 essential complexity and not introducing accidental 491 00:28:30,240 --> 00:28:31,760 complexity. Right. 492 00:28:31,960 --> 00:28:33,920 So I think that's really insightful, right? 493 00:28:33,920 --> 00:28:37,400 This is the first time I think I kind of like find the definition 494 00:28:37,400 --> 00:28:40,680 of modularity, you know, like the concept of knowledge 495 00:28:40,680 --> 00:28:43,400 boundaries, right? And you understand like the 496 00:28:43,400 --> 00:28:46,640 difference between modules and maybe components and things like 497 00:28:46,640 --> 00:28:48,640 that, right? And I think it's very important, 498 00:28:48,640 --> 00:28:49,800 right? When people talk about 499 00:28:49,800 --> 00:28:53,400 modularity, most of the times what they're doing is actually 500 00:28:53,400 --> 00:28:56,320 like create more abstractions, things like in object oriented 501 00:28:56,320 --> 00:28:58,240 programming, right? When you want to create more 502 00:28:58,240 --> 00:29:00,640 modular system, you create more abstractions, right? 503 00:29:00,960 --> 00:29:03,480 You introduce maybe interface, you know, abstract classes and 504 00:29:03,480 --> 00:29:06,120 things like that. First of all, is this the right 505 00:29:06,120 --> 00:29:07,920 way? And second thing, right, in your 506 00:29:07,920 --> 00:29:10,840 book you mentioned about module is actually a knowledge 507 00:29:10,840 --> 00:29:12,480 boundary. So I think this is also 508 00:29:12,480 --> 00:29:14,240 something very insightful, right? 509 00:29:14,240 --> 00:29:16,400 You are not talking about physical logical boundary 510 00:29:16,400 --> 00:29:18,840 anymore, but it's all about knowledge boundary. 511 00:29:19,200 --> 00:29:21,760 And maybe this is related to the shared knowledge that we 512 00:29:21,880 --> 00:29:24,200 discussed earlier. So tell us more about this 513 00:29:24,200 --> 00:29:26,920 abstraction and also about this knowledge boundary. 514 00:29:27,720 --> 00:29:31,760 Yeah, sure. So introducing abstractions it 515 00:29:31,760 --> 00:29:36,360 can be beneficial, but it can be a very effective way of 516 00:29:36,400 --> 00:29:38,120 introducing accidental complexity. 517 00:29:38,640 --> 00:29:43,600 Again, whether you're using it to manage the essential 518 00:29:43,600 --> 00:29:47,280 complexity or introducing new type of complexity depends on 519 00:29:47,600 --> 00:29:51,320 your concrete context. Now, one part of me want to say 520 00:29:51,320 --> 00:29:54,160 it depends and then advance to the next question, but I'm not 521 00:29:54,160 --> 00:29:57,080 going to do it. So let's talk about what it 522 00:29:57,080 --> 00:29:59,880 depends on. So let's say I have two 523 00:29:59,880 --> 00:30:03,120 components and I'm thinking whether they're going to 524 00:30:03,120 --> 00:30:06,920 interact with each other directly or should I introduce 525 00:30:06,920 --> 00:30:10,640 an abstraction between them that will encapsulate something? 526 00:30:11,120 --> 00:30:16,480 Now we have to ask, will that additional abstraction help us 527 00:30:16,920 --> 00:30:22,360 to encapsulate knowledge or in terms of David Pranas to hide 528 00:30:22,360 --> 00:30:28,040 some information, whether it will help us to use the boundary 529 00:30:28,040 --> 00:30:31,240 of one of the modules as a boundary of knowledge? 530 00:30:31,640 --> 00:30:35,000 So let's say I have a module that implements some 531 00:30:35,000 --> 00:30:37,160 functionality that is not trivial. 532 00:30:37,680 --> 00:30:39,360 Let's say it's going to be about encryption. 533 00:30:39,800 --> 00:30:42,080 Yeah. And let's say I made that very 534 00:30:42,080 --> 00:30:45,440 smart decision of implementing my own encryption algorithm. 535 00:30:45,800 --> 00:30:50,480 So one way for us to work together would be, I tell you, 536 00:30:50,480 --> 00:30:55,240 Henry, yesterday I had a few beers and I was thinking about 537 00:30:55,240 --> 00:30:58,600 that super secure encryption algorithm. 538 00:30:59,040 --> 00:31:02,920 So from now on, I'm going to communicate all the information 539 00:31:03,120 --> 00:31:06,760 encrypted with that algorithm in order to decrypt it. 540 00:31:07,080 --> 00:31:11,120 Here's what you have to do. And then I brain dump all that 541 00:31:11,200 --> 00:31:14,160 after beers thinking about that encryption algorithm on you and 542 00:31:14,160 --> 00:31:18,160 you have to implement in your code base in order to decrypt my 543 00:31:18,160 --> 00:31:21,000 data. What's going to happen is we 544 00:31:21,000 --> 00:31:24,960 have that knowledge of that probably dumb encryption 545 00:31:24,960 --> 00:31:27,160 algorithm duplicated in two places. 546 00:31:27,640 --> 00:31:31,840 One place is my module, which encrypts data, and the 2nd 547 00:31:31,840 --> 00:31:35,400 module is yours that has to decrypt that data. 548 00:31:35,880 --> 00:31:40,000 Of course, since I made that smart decision of coming up with 549 00:31:40,000 --> 00:31:42,880 an encryption algorithm, it's going to change. 550 00:31:43,000 --> 00:31:46,840 Probably there are going to be a security patch, let's say in 551 00:31:47,040 --> 00:31:51,080 after a few days. So now I will apply the change 552 00:31:51,080 --> 00:31:55,560 in my code base and I'll call in and say, Henry, that's urgent. 553 00:31:55,560 --> 00:31:59,800 You have to modify a few lines in that algorithm because 554 00:31:59,800 --> 00:32:02,400 otherwise you're not going to be able to decrypt my data. 555 00:32:03,000 --> 00:32:05,640 That's the effect of duplicating knowledge. 556 00:32:06,000 --> 00:32:08,320 Now, of course, that's a simplified example. 557 00:32:08,320 --> 00:32:11,760 In real life, we're talking about a business domain entities 558 00:32:11,760 --> 00:32:15,400 communicating with each other. But that is the same. 559 00:32:15,400 --> 00:32:17,280 We have that knowledge that is duplicated. 560 00:32:17,520 --> 00:32:21,560 Now we could have used a module to encapsulate that knowledge to 561 00:32:21,560 --> 00:32:23,800 hide that encryption algorithm in one place. 562 00:32:24,440 --> 00:32:27,560 And in that case, the functionality of that module 563 00:32:27,560 --> 00:32:29,320 would be encryption and decryption. 564 00:32:29,720 --> 00:32:33,560 It's interface would be probably 2 methods for encrypting and 565 00:32:33,560 --> 00:32:38,800 decrypting data, and it could be independently compiled, or it 566 00:32:38,800 --> 00:32:42,000 could be compiled within our monolithic code base. 567 00:32:42,000 --> 00:32:43,800 It doesn't matter, it's still a module. 568 00:32:44,320 --> 00:32:49,560 Now, if we compare the details of an encryption algorithm 569 00:32:49,960 --> 00:32:54,200 versus having an interface with two methods, encrypt and decrypt 570 00:32:54,200 --> 00:32:57,760 data, the difference between the two amounts of knowledge is 571 00:32:57,760 --> 00:33:01,440 substantial, right? In that case, that abstraction 572 00:33:01,440 --> 00:33:05,320 is going to be super useful. It manages the essential 573 00:33:05,320 --> 00:33:07,960 complexity. That encryption algorithm is 574 00:33:07,960 --> 00:33:13,520 encapsulated, so it helps us to make our system simpler because 575 00:33:13,760 --> 00:33:17,200 all those other components that will have to use it, they don't 576 00:33:17,200 --> 00:33:21,480 have to be aware of the internal details of that logic. 577 00:33:22,040 --> 00:33:26,160 On the other hand, let's say we're building a system and that 578 00:33:26,160 --> 00:33:30,440 pattern data transfer objects, it gets lots of hate. 579 00:33:30,880 --> 00:33:35,400 Like people are saying OK, so I have my business entities and 580 00:33:35,400 --> 00:33:39,320 then I have to introduce Dtos that are going to be on the 581 00:33:39,320 --> 00:33:45,120 boundary of my application and my APIs are going to return 582 00:33:45,120 --> 00:33:50,200 those Dtos right Now why people love to hate Dtos? 583 00:33:50,200 --> 00:33:54,200 Because in their code bases, usually what they are doing is 584 00:33:54,640 --> 00:33:58,640 translating one data structure to another data structure which 585 00:33:58,640 --> 00:34:01,280 looks exactly the same. So you have just basically 586 00:34:01,480 --> 00:34:05,120 copying values from one data structure to another one. 587 00:34:05,600 --> 00:34:10,320 However, as long as the attributes of those data 588 00:34:10,320 --> 00:34:13,560 structures, those types of those attributes, are exactly the 589 00:34:13,560 --> 00:34:18,679 same, we're not actually encapsulating any knowledge by 590 00:34:18,679 --> 00:34:22,480 introducing that abstraction. What we're doing is we're 591 00:34:22,480 --> 00:34:27,920 introducing another moving part. We're introducing another object 592 00:34:27,920 --> 00:34:31,880 or another class that we'll have to think about. 593 00:34:32,159 --> 00:34:36,639 When we are going to change our model, we'll probably have to 594 00:34:36,840 --> 00:34:39,120 apply the same change. Let's say we want to change the 595 00:34:39,120 --> 00:34:44,960 name of a field in both places. Now in this case, that DTO is 596 00:34:44,960 --> 00:34:47,840 not an effective obstruction. It increases complexity. 597 00:34:47,840 --> 00:34:50,360 It introduces accidental complexity. 598 00:34:50,760 --> 00:34:53,080 Now, am I saying that DT OS are bad? 599 00:34:53,120 --> 00:34:56,920 Of course not. I just gave you an example in 600 00:34:56,920 --> 00:35:00,720 which DT OS are useless. Sorry, maybe not useless, but 601 00:35:00,720 --> 00:35:04,120 they're not providing the value. But on the other hand, they're 602 00:35:04,120 --> 00:35:06,880 introducing another something you have to think about. 603 00:35:07,200 --> 00:35:10,200 And the more things you have to think about, the more the 604 00:35:10,200 --> 00:35:15,520 cognitive load and our cognitive load limits are not looking 605 00:35:15,520 --> 00:35:18,520 good. There were studies done in 50s, 606 00:35:18,600 --> 00:35:23,600 then repeated in 2000, and they were not that spectacular early 607 00:35:23,600 --> 00:35:27,160 on and the number was reduced 50 years later. 608 00:35:27,160 --> 00:35:31,400 And yeah, So going back to your question of abstractions, it 609 00:35:31,400 --> 00:35:34,600 depends. If abstraction helps you to 610 00:35:34,600 --> 00:35:36,680 encapsulate knowledge, it's effective. 611 00:35:37,240 --> 00:35:41,480 If it doesn't, then it's just going to introduce additional 612 00:35:41,480 --> 00:35:45,120 moving parts and you'll end up increasing the accidental 613 00:35:45,120 --> 00:35:48,680 complexity of the system. I'm so glad that you brought up 614 00:35:48,680 --> 00:35:51,560 the DTO discussion, right? Because I think, yeah, it's like 615 00:35:51,560 --> 00:35:54,640 a love hate kind of a pattern for some people, they find it 616 00:35:54,680 --> 00:35:57,480 like a more work in terms of creating the APIs. 617 00:35:57,480 --> 00:36:00,320 You know, you have to build this translation, which is probably 618 00:36:00,320 --> 00:36:02,640 the same when you build the system first time, right? 619 00:36:02,640 --> 00:36:04,680 It's like mapping the same kind of data structure. 620 00:36:05,040 --> 00:36:07,480 But I think if you think about it, if the system evolves, the 621 00:36:07,480 --> 00:36:10,600 API evolves, and your implementation details changes 622 00:36:10,600 --> 00:36:13,280 over time, maybe the database, how you store the data changes, 623 00:36:13,280 --> 00:36:15,240 right? The detail is like a boundary, 624 00:36:15,240 --> 00:36:17,280 right? A contract that you probably 625 00:36:17,360 --> 00:36:19,960 pass on with the other teams or the other service, and that 626 00:36:19,960 --> 00:36:22,920 doesn't change as long as you create this proper abstraction. 627 00:36:23,280 --> 00:36:24,800 So I think thanks for bringing that up. 628 00:36:25,120 --> 00:36:27,480 Let's move to the next topic. I know that we can probably talk 629 00:36:27,480 --> 00:36:30,600 a lot more about complexity and modularity, but I think I want 630 00:36:30,600 --> 00:36:33,800 to bring up another fascinating thing that you brought up in the 631 00:36:33,800 --> 00:36:36,320 book, right? It's actually how to measure 632 00:36:36,400 --> 00:36:37,920 coupling. So in the beginning, you 633 00:36:37,920 --> 00:36:40,640 mentioned like sometimes it's very hard to actually put a 634 00:36:40,640 --> 00:36:43,120 number of how coupled is our code, right? 635 00:36:43,440 --> 00:36:47,240 It's always like a, you know, rough idea, maybe estimation. 636 00:36:47,240 --> 00:36:50,120 But actually in your book, you bring three different dimensions 637 00:36:50,120 --> 00:36:54,000 that we can use to kind of like quantify complexity, coupling 638 00:36:54,000 --> 00:36:56,360 and things like that. And you brought up the point 639 00:36:56,360 --> 00:37:00,640 about integration, strength, space or distance and time or 640 00:37:00,640 --> 00:37:03,000 volatility. So maybe, I know it's pretty 641 00:37:03,000 --> 00:37:06,560 hard to explain all three at the same time, but maybe if you can 642 00:37:06,560 --> 00:37:09,160 elaborate, what are these 3 dimensions dimensions, How can 643 00:37:09,160 --> 00:37:12,720 we use them to actually assess the complexity or the levels of 644 00:37:12,720 --> 00:37:14,880 coupling of our code base? Yeah. 645 00:37:14,880 --> 00:37:20,480 So evaluating coupling is something that we are trying to 646 00:37:20,480 --> 00:37:25,760 do for ages now, I think since 60s when the structure design 647 00:37:25,760 --> 00:37:28,720 methodology was coined. They started working on it in 648 00:37:28,720 --> 00:37:31,160 late 60s. So they introduced a model for 649 00:37:31,160 --> 00:37:33,960 evaluating coupling. Then there was kinesins and then 650 00:37:33,960 --> 00:37:40,440 there were some metrics and those metrics try to put a 651 00:37:40,440 --> 00:37:43,720 number on on coupling. The problem with that approach 652 00:37:43,720 --> 00:37:49,800 is that it was based on counting variables or counting methods. 653 00:37:50,320 --> 00:37:55,640 But is that number something that you can really, really 654 00:37:55,640 --> 00:37:59,800 trust? And there is a talk that I did 655 00:37:59,800 --> 00:38:03,720 at a few conferences with my friend Sonia Natanzon in which 656 00:38:04,360 --> 00:38:08,200 we're talking about software design metrics and basically 657 00:38:08,200 --> 00:38:10,200 saying that you shouldn't trust them. 658 00:38:11,240 --> 00:38:15,080 And there is a metric called stability, which is about the 659 00:38:15,080 --> 00:38:17,960 relationship between the incoming connections and 660 00:38:17,960 --> 00:38:21,400 outgoing connections, afferent coupling and afferent coupling 661 00:38:21,840 --> 00:38:25,760 as an ASL speaker really hate these terms, like passionately. 662 00:38:26,240 --> 00:38:32,240 That metric says that if there are more modules that depend on 663 00:38:32,240 --> 00:38:36,240 you, then the number of modules you depend on, then your 664 00:38:36,240 --> 00:38:37,840 stability score is going to be higher. 665 00:38:38,320 --> 00:38:42,680 So in that talk I'm showing an example which is supposed to be 666 00:38:42,760 --> 00:38:49,000 perfect from that sense. Like a module that let's say 100 667 00:38:49,000 --> 00:38:54,400 other modules depend on it, and our module only depends on one 668 00:38:54,440 --> 00:38:56,680 other external component. That's it. 669 00:38:56,760 --> 00:39:00,640 So the ratio is one to 100. So it's supposed to be super 670 00:39:00,640 --> 00:39:03,360 stable. However, again, as I mentioned a 671 00:39:03,360 --> 00:39:06,120 couple of times, the devil is in the details. 672 00:39:06,640 --> 00:39:10,880 And on the next slide I'm showing how that one dependency 673 00:39:10,880 --> 00:39:14,320 is implemented. And what I'm showing is that it 674 00:39:14,320 --> 00:39:18,480 uses reflection to read a value of private field. 675 00:39:19,040 --> 00:39:23,640 So what's going to happen? Well, once I'm introducing that 676 00:39:23,640 --> 00:39:26,720 dependency on an implementation detail, any change the 677 00:39:26,720 --> 00:39:29,400 implementation details of that external module has the 678 00:39:29,400 --> 00:39:31,280 potential of breaking my component. 679 00:39:31,720 --> 00:39:35,160 Now, once I have something that has to be changed in my 680 00:39:35,160 --> 00:39:39,280 component, then I have 100 other dependencies that are probably 681 00:39:39,280 --> 00:39:43,360 going to be affected by it. So now what we're getting is a 682 00:39:43,560 --> 00:39:47,560 perfect stability score. Ended up being big bowl of mud 683 00:39:47,760 --> 00:39:53,560 basically. So that's why initially I try to 684 00:39:53,560 --> 00:39:58,520 avoid putting numeric values on coupling, because it's all about 685 00:39:58,600 --> 00:40:03,440 details, Details that are hard to quantify and hard to 686 00:40:03,440 --> 00:40:06,280 describe. So instead, in the book I 687 00:40:06,280 --> 00:40:09,600 propose a different model of evaluating coupling that is 688 00:40:09,680 --> 00:40:12,000 based on three dimensions as you mentioned. 689 00:40:12,480 --> 00:40:17,040 The first one is the dimension that measures the knowledge. 690 00:40:17,440 --> 00:40:21,400 What is the amount of knowledge that is shared between two 691 00:40:21,400 --> 00:40:25,080 connected components? How do you measure knowledge? 692 00:40:25,400 --> 00:40:28,920 Can you put it on a scale and have a number next to it? 693 00:40:28,920 --> 00:40:31,040 Of course not. Maybe someday, I don't know. 694 00:40:31,400 --> 00:40:35,160 By the way, when I was doing talks at conferences on this 695 00:40:35,160 --> 00:40:38,840 subject, almost always somebody from audience says that, hey, 696 00:40:38,840 --> 00:40:43,440 you really have to think about a way of doing this automatically, 697 00:40:43,520 --> 00:40:45,120 of evaluating knowledge in the book. 698 00:40:45,120 --> 00:40:48,680 I said, OK, I tried, I failed. That's topic for further 699 00:40:48,680 --> 00:40:50,720 research. If you want to do it, good luck, 700 00:40:51,240 --> 00:40:53,400 I'll be happy. So knowledge. 701 00:40:53,880 --> 00:40:56,000 So we cannot put a number in it yet. 702 00:40:56,520 --> 00:41:02,520 However, we can look at that early work, back from late 60s, 703 00:41:02,520 --> 00:41:08,000 early 70s, the structure design methodology, and back then they 704 00:41:08,000 --> 00:41:10,360 introduced a model called Module coupling. 705 00:41:10,840 --> 00:41:16,160 It had 6 levels that are kind of challenging to apply in our 706 00:41:16,160 --> 00:41:20,920 modern systems because that model is based on languages such 707 00:41:20,920 --> 00:41:24,600 as COBOL and Fortran. It's like fun, but the opposite 708 00:41:24,600 --> 00:41:28,280 of fun. Instead of having to learn those 709 00:41:28,400 --> 00:41:31,920 languages and what those keywords mean and how to adapt 710 00:41:31,920 --> 00:41:36,800 to translate them to our world. In the balancing coupling book, 711 00:41:36,880 --> 00:41:39,440 I proposed a different model. I called it integration 712 00:41:39,440 --> 00:41:42,600 strength. It is based both on structured 713 00:41:42,600 --> 00:41:45,360 designs model and another one. I'll talk about it in a minute. 714 00:41:45,720 --> 00:41:50,400 So basically it adapts the six levels of integration strength 715 00:41:50,480 --> 00:41:53,280 into terminology. That's going to be more 716 00:41:53,280 --> 00:41:57,800 convenient for us today. The four terms are contract 717 00:41:57,800 --> 00:42:00,120 model, functional, and intrusive coupling. 718 00:42:00,520 --> 00:42:04,000 They are not defining the amount of knowledge, they're defining 719 00:42:04,040 --> 00:42:07,560 the type of knowledge. So let's start from the biggest 720 00:42:07,560 --> 00:42:11,160 one, intrusive coupling. This one means that I'm using 721 00:42:11,160 --> 00:42:14,360 something other than public interfaces for integration. 722 00:42:14,720 --> 00:42:17,680 Let's say I'm using reflection, let's say I'm using another 723 00:42:17,680 --> 00:42:21,560 micro services database directly, or something else, 724 00:42:21,560 --> 00:42:24,560 whatever that wasn't intended for integration. 725 00:42:24,960 --> 00:42:28,080 I'm introducing an intrusion into it's boundaries. 726 00:42:28,320 --> 00:42:30,000 That's why it's called intrusive coupling. 727 00:42:30,400 --> 00:42:34,840 Now, once we are introducing intrusive coupling, we have to 728 00:42:34,840 --> 00:42:39,920 assume that the author of that module might have no clue that 729 00:42:39,920 --> 00:42:43,920 we're doing that thing, which means almost any change that 730 00:42:44,200 --> 00:42:46,960 they're applying has the potential of breaking the 731 00:42:46,960 --> 00:42:49,760 integration. So lots of knowledge. 732 00:42:50,160 --> 00:42:52,280 The integration interface is fragile. 733 00:42:52,320 --> 00:42:55,720 It's implicit, so expect cascading changes. 734 00:42:56,360 --> 00:42:59,760 Another type of knowledge that can be shared is the knowledge 735 00:42:59,920 --> 00:43:03,760 of functional requirements. I called it functional coupling. 736 00:43:04,280 --> 00:43:08,920 If previous one was about how that upstream module or 737 00:43:08,920 --> 00:43:12,320 component is implemented, this one is about what is the 738 00:43:12,320 --> 00:43:15,360 functionality that the component is implementing. 739 00:43:15,840 --> 00:43:20,120 Now let's say that we have two components and they implement 740 00:43:20,120 --> 00:43:22,000 closely related business functionalities. 741 00:43:22,320 --> 00:43:25,920 That means that probably they will have to change 742 00:43:25,920 --> 00:43:28,800 simultaneously because of the same changes in business 743 00:43:28,800 --> 00:43:31,120 requirements. That means we have functional 744 00:43:31,120 --> 00:43:33,640 coupling. An extreme example of functional 745 00:43:33,640 --> 00:43:36,800 coupling would be let's say we have the same business rule 746 00:43:36,840 --> 00:43:41,000 implemented in two places or the same business algorithm or the 747 00:43:41,000 --> 00:43:43,480 same business invariant. And from the business 748 00:43:43,480 --> 00:43:47,640 standpoint, if the requirements or the definition of that rule 749 00:43:47,640 --> 00:43:51,720 changes, they have to change simultaneously because otherwise 750 00:43:51,720 --> 00:43:54,640 the system is going to be in an invalid state. 751 00:43:55,040 --> 00:43:58,760 In that case, we have a very strong case of functional 752 00:43:58,760 --> 00:44:00,640 coupling. By the way, they don't have to 753 00:44:00,640 --> 00:44:03,520 be physically connected. I call it wireless coupling. 754 00:44:03,960 --> 00:44:06,960 Another case of functional coupling is, let's say we have 755 00:44:06,960 --> 00:44:12,160 multiple operations that require concurrency control, probably 756 00:44:12,160 --> 00:44:14,720 because they're going to work on the same set of data, right? 757 00:44:15,200 --> 00:44:17,720 In that case, again, functional coupling. 758 00:44:18,080 --> 00:44:22,560 Or maybe we have operations or functionalities that have to be 759 00:44:22,560 --> 00:44:25,640 implemented in a specific order, one after another. 760 00:44:26,080 --> 00:44:28,440 That's also case of functional coupling. 761 00:44:28,960 --> 00:44:32,840 That requirement of being executed in a specific order is 762 00:44:32,840 --> 00:44:37,520 probably there for a reason. Probably it introduces some kind 763 00:44:37,520 --> 00:44:42,320 of business dependency there. So that's the level of 764 00:44:42,320 --> 00:44:43,560 functional coupling. Here. 765 00:44:43,560 --> 00:44:46,640 We are sharing the knowledge of our business requirements. 766 00:44:47,120 --> 00:44:50,800 Now to implement those business requirements, usually we have to 767 00:44:50,800 --> 00:44:55,520 model a business domain. We have to understand what's the 768 00:44:55,520 --> 00:44:59,320 system we are implementing and define a model that represent 769 00:44:59,400 --> 00:45:01,920 that business domain. And then we are going to 770 00:45:01,920 --> 00:45:05,920 implement the functionality, the requirements in code using that 771 00:45:05,920 --> 00:45:08,360 model. If you have two components that 772 00:45:08,360 --> 00:45:12,360 are based on the same model, which means if the model changes 773 00:45:12,680 --> 00:45:15,920 both of them have to change, then you have model coupling. 774 00:45:16,320 --> 00:45:19,520 And finally the lowest level is contract coupling. 775 00:45:20,080 --> 00:45:23,720 So contract coupling we can think about it as a model of a 776 00:45:23,720 --> 00:45:26,360 model. Remember the discussion about DT 777 00:45:26,480 --> 00:45:29,080 OS? I used an illustration of an 778 00:45:29,080 --> 00:45:33,920 ineffective DTO and then you handry elaborated and discussed 779 00:45:34,080 --> 00:45:38,120 an effective use of DT OS. In that case, those effective 780 00:45:38,120 --> 00:45:41,320 details are contracts, integration contracts. 781 00:45:41,520 --> 00:45:45,600 That's a model of a model that was crafted with the purpose of 782 00:45:45,920 --> 00:45:49,160 encapsulating that model that's being used internally. 783 00:45:49,560 --> 00:45:53,600 Whenever that model changes, we can contain those changes behind 784 00:45:53,600 --> 00:45:57,280 the same integration contract. So we are minimizing the 785 00:45:57,280 --> 00:45:59,920 knowledge that we are sharing across our boundary. 786 00:46:00,520 --> 00:46:03,640 So overall, these are four types of knowledge. 787 00:46:03,840 --> 00:46:08,640 We can share the knowledge about our integration contracts, about 788 00:46:08,640 --> 00:46:12,160 how we see and how we think about the business domain. 789 00:46:12,200 --> 00:46:15,240 It's model, model coupling. Then we can share knowledge 790 00:46:15,240 --> 00:46:18,000 about our business requirements, functional coupling. 791 00:46:18,480 --> 00:46:21,280 And finally, we can share knowledge about our 792 00:46:21,280 --> 00:46:23,920 implementation details and that's intrusive coupling. 793 00:46:24,360 --> 00:46:29,440 So overall, these 4 levels are not going to put an exact number 794 00:46:29,880 --> 00:46:32,000 on the weight of knowledge you're sharing. 795 00:46:32,360 --> 00:46:36,560 However, these are four different types that signal 796 00:46:36,640 --> 00:46:39,240 different amounts of knowledge that's been shared. 797 00:46:39,720 --> 00:46:42,880 Now if you're going to read the book, then you'll see that each 798 00:46:43,000 --> 00:46:47,440 one of these types has also degrees except for intrusive 799 00:46:47,440 --> 00:46:49,680 coupling, functional model, and contract coupling. 800 00:46:49,680 --> 00:46:54,080 They have degrees so that first of all you can compared to 801 00:46:54,320 --> 00:46:58,760 designs of the same integration strength and also to give you a 802 00:46:58,760 --> 00:47:02,360 more fine grain control on the knowledge that's being shared 803 00:47:02,360 --> 00:47:04,840 there. So again, integration strength 804 00:47:04,840 --> 00:47:09,280 overall 4 levels and three of them have degrees. 805 00:47:09,880 --> 00:47:14,880 Now the four levels are based on the structure designs, module 806 00:47:14,880 --> 00:47:21,120 coupling model from late 60s, early 70s and those degrees that 807 00:47:21,200 --> 00:47:24,160 I'm using for functional model and contract coupling are based 808 00:47:24,160 --> 00:47:28,840 on a model called Kinesis which was introduced in 90s. 809 00:47:29,200 --> 00:47:32,080 So integration strength kind of combines both. 810 00:47:32,640 --> 00:47:36,680 Let's say that you evaluated that knowledge using integration 811 00:47:36,680 --> 00:47:39,920 strength, You have two components and you identified 812 00:47:39,960 --> 00:47:42,960 what is the knowledge that's been exchanged between them. 813 00:47:43,440 --> 00:47:47,120 Does it say that let's say functional coupling is 814 00:47:47,160 --> 00:47:51,120 necessarily bad, or model coupling, is it worse than a 815 00:47:51,120 --> 00:47:54,600 contract coupling? Well, it depends If you can 816 00:47:54,840 --> 00:47:57,120 reduce it, of course you have to reduce it. 817 00:47:57,720 --> 00:48:01,760 If you can turn a model coupling into concert coupling, probably 818 00:48:01,760 --> 00:48:03,560 you should do it, but not always. 819 00:48:03,680 --> 00:48:07,960 Sometimes you have to share a model, or sometimes you have to 820 00:48:07,960 --> 00:48:09,480 share business requirements, right? 821 00:48:09,760 --> 00:48:12,240 Does it mean that your design is bad? 822 00:48:12,360 --> 00:48:16,600 No, it depends on the next dimension, the dimension of 823 00:48:16,720 --> 00:48:19,160 distance between those connected components. 824 00:48:19,680 --> 00:48:23,200 Now, since the beginning of our discussion, I was using abstract 825 00:48:23,200 --> 00:48:25,880 terms to describe systems. I was saying we have sets of 826 00:48:25,880 --> 00:48:28,480 components. I purposefully didn't mention 827 00:48:28,480 --> 00:48:31,640 whether those components are methods, objects, services, or 828 00:48:31,640 --> 00:48:35,640 whole systems or whatever. That's because we can introduce 829 00:48:35,640 --> 00:48:39,120 coupling across different levels of abstraction. 830 00:48:39,440 --> 00:48:42,480 We can have coupling between methods, coupling between 831 00:48:42,480 --> 00:48:46,320 objects, coupling between modules, namespaces, services, 832 00:48:46,320 --> 00:48:47,800 whatever. Whole systems. 833 00:48:48,440 --> 00:48:53,440 Now the higher we go on that layer of abstraction scale, the 834 00:48:53,440 --> 00:48:58,400 higher the physical distance between the source code in which 835 00:48:58,400 --> 00:48:59,920 those components are implemented. 836 00:49:00,240 --> 00:49:02,960 Like extreme case, let's say you have two methods within the same 837 00:49:02,960 --> 00:49:04,240 class. Probably they are going to be 838 00:49:04,240 --> 00:49:06,680 close to each other, probably in the same file, right? 839 00:49:07,280 --> 00:49:09,800 Different objects, probably different files, different 840 00:49:09,800 --> 00:49:13,120 namespaces, different folders, different services, maybe 841 00:49:13,120 --> 00:49:16,520 different repositories, different systems, maybe 842 00:49:16,520 --> 00:49:20,480 different companies, etcetera. So the higher you are on that 843 00:49:20,480 --> 00:49:23,560 scale feel longer the distance. Why is that important? 844 00:49:24,080 --> 00:49:27,560 It's important because if you combine it with the knowledge, 845 00:49:27,960 --> 00:49:31,640 you get a sense of whether you're going towards complexity 846 00:49:31,640 --> 00:49:35,400 or towards modularity. Because let's say that you have 847 00:49:35,840 --> 00:49:39,600 two components with functional coupling between them, which 848 00:49:39,600 --> 00:49:42,920 means they're sharing a lot of knowledge and you're putting 849 00:49:42,920 --> 00:49:46,640 them in separate micro services, which means the distance between 850 00:49:46,640 --> 00:49:50,480 them is big as well. Now that functional company kind 851 00:49:50,480 --> 00:49:53,600 of implies that we're sharing lots of knowledge. 852 00:49:53,600 --> 00:49:56,400 So if something is going to change in that knowledge, that 853 00:49:56,400 --> 00:49:58,400 change is going to be propagated across the boundary. 854 00:49:58,400 --> 00:50:01,560 So both of them are going to be changed simultaneously. 855 00:50:01,840 --> 00:50:05,920 Now, if the distance is big, it is going to be an easy change. 856 00:50:06,440 --> 00:50:08,480 Probably not. The bigger the distance and the 857 00:50:08,480 --> 00:50:12,160 harder it is, the harder it is going to be to imply the change. 858 00:50:12,760 --> 00:50:16,520 In other words, we can say that the bigger that distance, the 859 00:50:16,520 --> 00:50:20,680 more coordination effort will be needed to implement a change 860 00:50:20,720 --> 00:50:22,920 that affects both couple components. 861 00:50:23,400 --> 00:50:28,920 So if we have both integration strength and distance high, we 862 00:50:28,920 --> 00:50:31,680 get complexity. We're looking at the system in 863 00:50:31,680 --> 00:50:33,720 which we want to change the component. 864 00:50:34,080 --> 00:50:37,560 But in order to understand the effects of that change, we have 865 00:50:37,560 --> 00:50:42,160 to investigate components that are located far away from us and 866 00:50:42,160 --> 00:50:43,760 maybe in different repositories even. 867 00:50:44,080 --> 00:50:45,040 Is it easy? No. 868 00:50:45,240 --> 00:50:48,680 Will it require a cognitive efforts, lots of them, right. 869 00:50:48,680 --> 00:50:52,680 So that will result in cognitive load and as a result it will 870 00:50:52,680 --> 00:50:56,120 result in complexity. Now what if we do the opposite 871 00:50:56,120 --> 00:50:58,480 of that? Let's say we have two components 872 00:50:58,480 --> 00:51:01,920 that I'm not sharing knowledge. Let's say we are on that 873 00:51:02,200 --> 00:51:05,280 contract coupling level. So we're putting them close to 874 00:51:05,280 --> 00:51:10,480 each other in the same a module, the same namespace, the same 875 00:51:10,480 --> 00:51:13,920 package with the recalled. So both values are low. 876 00:51:14,360 --> 00:51:18,680 And if all we have is 2 components, that probably, yeah, 877 00:51:18,680 --> 00:51:21,440 who cares. But usually in real system, it's 878 00:51:21,440 --> 00:51:23,920 not going to be two, It's going to be way more. 879 00:51:24,200 --> 00:51:28,120 And once you have way more unrelated things located close 880 00:51:28,120 --> 00:51:32,000 to each other, then when you have to make a change, you 881 00:51:32,000 --> 00:51:35,080 suddenly have to find that thing you have to change, right? 882 00:51:35,640 --> 00:51:38,600 And the more options you have, the higher the cognitive load, 883 00:51:38,880 --> 00:51:41,320 the higher the cognitive load as a result, the higher the 884 00:51:41,320 --> 00:51:44,480 complexity. So at this point, we can 885 00:51:44,600 --> 00:51:49,520 identify complexity as a situation in which integration 886 00:51:49,520 --> 00:51:53,320 strength is equal to distance, both are low or both are high, 887 00:51:53,640 --> 00:51:56,680 we get complexity. Now, what is modularity event? 888 00:51:57,120 --> 00:51:59,680 Well, modularity is the opposite of complexity. 889 00:52:00,080 --> 00:52:03,080 If you're working on modular system, you should know exactly 890 00:52:03,080 --> 00:52:05,720 what the effect of a change is going to be. 891 00:52:06,240 --> 00:52:10,400 So we can apply it here as well. Let's say that if complexity is 892 00:52:10,520 --> 00:52:14,280 in the case of both strength and distance being equal, then 893 00:52:14,280 --> 00:52:16,000 modularity is when they're not equal. 894 00:52:16,040 --> 00:52:20,920 And again, extreme examples, if you have high integration 895 00:52:20,920 --> 00:52:25,040 strength and there is no way for you to reduce it because that's 896 00:52:25,040 --> 00:52:27,960 the business domain, that's your essential complexity, deal with 897 00:52:27,960 --> 00:52:33,440 it, then how can you manage it? Well, you can put those closer 898 00:52:33,440 --> 00:52:34,840 related things close to each other. 899 00:52:34,840 --> 00:52:36,520 You can minimize the distance between them. 900 00:52:36,880 --> 00:52:40,200 Yes, they will have to change together, but once they're close 901 00:52:40,200 --> 00:52:43,920 to each other, the cognitive load on you is going to be lower 902 00:52:43,920 --> 00:52:47,560 because it's almost like modifying the same thing or vice 903 00:52:47,560 --> 00:52:49,720 versa. Let's say we have minimal 904 00:52:49,840 --> 00:52:52,360 knowledge shared across couple components. 905 00:52:52,360 --> 00:52:55,360 We have contract coupling. Well, what should we do? 906 00:52:55,800 --> 00:52:57,120 The distance should be the opposite. 907 00:52:57,400 --> 00:53:00,360 Let's spread them apart. Let's spread them across, let's 908 00:53:00,360 --> 00:53:03,120 say name spaces or services, whatever. 909 00:53:03,720 --> 00:53:07,400 Instead, in those resultant services, we'll put only things 910 00:53:07,400 --> 00:53:11,960 that are related to our modules, in other words, those that do 911 00:53:11,960 --> 00:53:16,840 have high integration strength. So that's the relationship 912 00:53:16,840 --> 00:53:19,960 between distance and integration strength. 913 00:53:20,120 --> 00:53:24,720 We can use them for evaluating complexity and modularity of the 914 00:53:24,720 --> 00:53:27,280 code base. Now there is other dimension, 915 00:53:27,440 --> 00:53:31,280 and that's the dimension of time or the dimension of cutting 916 00:53:31,280 --> 00:53:33,760 corners. I call it being pragmatic. 917 00:53:34,440 --> 00:53:39,120 Let's say we have two components with functional coupling between 918 00:53:39,120 --> 00:53:40,840 them. No, not functional. 919 00:53:40,840 --> 00:53:43,600 Let's say intrusive coupling between them and big distance 920 00:53:43,600 --> 00:53:46,680 between them. Let's say we have two systems. 921 00:53:47,000 --> 00:53:49,840 Once we're talking about systems, then the distance is 922 00:53:49,840 --> 00:53:53,960 big and we are introducing intrusive coupling between them. 923 00:53:54,360 --> 00:53:58,680 Is that design necessarily bad? Well, that's tricky question 924 00:53:58,680 --> 00:54:02,560 because from complexity standpoint, we should say yes, 925 00:54:02,840 --> 00:54:06,760 right? However, what if that upstream 926 00:54:06,760 --> 00:54:09,560 system is not going to change? Never. 927 00:54:09,880 --> 00:54:13,680 Let's say it's a legacy system and you have to integrate with 928 00:54:13,680 --> 00:54:17,840 it, and that system is dead. Like in your company, nobody has 929 00:54:17,840 --> 00:54:21,040 that courage of touching it, but you still have to integrate with 930 00:54:21,040 --> 00:54:23,840 it. So should you roll up your 931 00:54:23,840 --> 00:54:29,040 sleeves and get your hands dirty and implement additional 932 00:54:29,040 --> 00:54:32,000 endpoints for proper integrations through contract 933 00:54:32,000 --> 00:54:34,080 coupling? You probably could. 934 00:54:34,080 --> 00:54:38,760 However, given that that's a legacy system and it's not going 935 00:54:38,760 --> 00:54:44,400 to change, it's fine to take its data from its database, for 936 00:54:44,400 --> 00:54:46,640 example. So yeah, you are introducing 937 00:54:46,640 --> 00:54:50,280 intrusive coupling. However, since the volatility of 938 00:54:50,280 --> 00:54:54,960 that upstream system is low, then you are not going to feel 939 00:54:55,080 --> 00:54:58,960 any pain in your future because of that intrusive coupling. 940 00:54:59,480 --> 00:55:01,440 So overall, we have 3 dimensions. 941 00:55:01,440 --> 00:55:06,520 We have integration, strength and distance for showing us the 942 00:55:06,520 --> 00:55:09,440 way, whether we're headed towards complexity or towards 943 00:55:09,440 --> 00:55:12,760 modularity. And we have that dimension that 944 00:55:12,760 --> 00:55:16,760 can help us to make pragmatic decisions based on the 945 00:55:16,960 --> 00:55:21,160 volatility of our components. Now, if you combine the three of 946 00:55:21,160 --> 00:55:25,160 them together, basically if you're into domain driven 947 00:55:25,160 --> 00:55:28,240 design, then supplying subdomains, generics, when 948 00:55:28,240 --> 00:55:32,080 you're integrating generic subdomains, I say that it's OK 949 00:55:32,080 --> 00:55:35,560 to cut cores. That's something that usually is 950 00:55:35,560 --> 00:55:39,040 implemented, as Eric Evans says, with a rapid application 951 00:55:39,040 --> 00:55:42,120 development framework. Is it going to be super modular? 952 00:55:42,120 --> 00:55:43,720 Probably not. Why is it OK? 953 00:55:43,720 --> 00:55:46,720 Because those subdomains are not going to change frequently. 954 00:55:47,000 --> 00:55:49,760 Core subdomains, on the other hand, that's where I should 955 00:55:49,760 --> 00:55:53,600 expect your changes and that's not a place to cut corners. 956 00:55:53,800 --> 00:55:55,760 That's a place where you want modularity. 957 00:55:56,080 --> 00:56:00,040 And if you follow the management design that aggregates basically 958 00:56:00,080 --> 00:56:03,240 take the idea of functional coupling to extreme, we have 959 00:56:03,240 --> 00:56:07,640 those transactional boundaries. So we are putting all those 960 00:56:07,640 --> 00:56:11,680 entities that share those transactional boundaries within 961 00:56:11,680 --> 00:56:15,200 the same aggregate bounded context are there to protect our 962 00:56:15,200 --> 00:56:18,000 models. So we can use the same model of 963 00:56:18,000 --> 00:56:21,320 the business domain within bounded context, but not a cross 964 00:56:21,320 --> 00:56:24,240 bounded context. Cross bounded context, we need 965 00:56:24,280 --> 00:56:26,480 integration contracts in the language. 966 00:56:26,480 --> 00:56:29,680 These are open host service, published language or anti 967 00:56:29,680 --> 00:56:31,200 corruption layer. Yeah. 968 00:56:31,200 --> 00:56:34,240 And if you analyze design patterns, architectural 969 00:56:34,240 --> 00:56:38,640 patterns, or cases where people are saying that one pattern is 970 00:56:39,040 --> 00:56:42,280 evil and should be considered harmful versus people saying 971 00:56:42,280 --> 00:56:46,960 that that pattern will save your life, well, consider those 972 00:56:46,960 --> 00:56:50,720 extreme opinions from the perspective of those 3 973 00:56:50,720 --> 00:56:53,000 dimensions. Probably you're going to find 974 00:56:53,000 --> 00:56:56,520 the explanation for those conflicting opinions in one of 975 00:56:56,520 --> 00:57:00,480 those dimensions. Wow, I think I feel like I am 976 00:57:00,480 --> 00:57:03,320 listening to like a insightful lecture, right? 977 00:57:03,320 --> 00:57:06,280 So I think what you just explained, right, with different 978 00:57:06,280 --> 00:57:09,280 scenarios, different kind of permutations, I think it kind of 979 00:57:09,280 --> 00:57:11,880 like opens up our eyes a bit, right? 980 00:57:11,960 --> 00:57:14,000 Like how do you analyze complexity? 981 00:57:14,240 --> 00:57:17,120 How do you analyze things that probably it's a bit difficult to 982 00:57:17,120 --> 00:57:19,160 change. Probably also think about 983 00:57:19,160 --> 00:57:21,800 dealing with legacy and you bring in your bread and butter 984 00:57:21,800 --> 00:57:25,120 DDD concept as well, right? As you probably write through 985 00:57:25,120 --> 00:57:26,640 the last chapters of the book, right? 986 00:57:26,880 --> 00:57:30,440 I think all these kind of like now starting to get more sense, 987 00:57:30,440 --> 00:57:31,920 right? You bring up the topic of 988 00:57:31,920 --> 00:57:35,240 coupling, but also you bring up the topic of architecture design 989 00:57:35,600 --> 00:57:38,840 and also DDD itself, right? I hope people by listening to 990 00:57:38,840 --> 00:57:42,120 this episode are maybe better by reading your book, actually gets 991 00:57:42,120 --> 00:57:45,520 more tools to actually discuss about software design. 992 00:57:45,520 --> 00:57:48,200 Because yeah, these three different dimensions are really, 993 00:57:48,200 --> 00:57:51,000 really critical if you want to talk about the complexity, 994 00:57:51,000 --> 00:57:54,000 modularity of the system, right? And whether your system actually 995 00:57:54,320 --> 00:57:56,720 can take the trade off, right? Because coupling, as you 996 00:57:56,720 --> 00:57:59,880 mentioned right in the book, you cannot really eliminate coupling 997 00:57:59,960 --> 00:58:01,600 because the software has to work together. 998 00:58:01,600 --> 00:58:02,880 There will be a level of coupling. 999 00:58:03,320 --> 00:58:06,000 Whether the high coupling is bad, again, it depends on the 1000 00:58:06,000 --> 00:58:07,880 context, right? If it's not so volatile, 1001 00:58:07,880 --> 00:58:10,280 probably it's not so bad. And you bring in the topic of 1002 00:58:10,280 --> 00:58:13,320 DDD. So maybe as we move on to maybe 1003 00:58:13,320 --> 00:58:16,000 the later part of our conversation, I hope you still 1004 00:58:16,000 --> 00:58:18,920 have the time, right? So in your last part of the 1005 00:58:18,920 --> 00:58:21,720 book, after we understand about definition of coupling, we 1006 00:58:21,720 --> 00:58:24,840 understand about 3 dimensions of coupling, how we assess our 1007 00:58:24,840 --> 00:58:27,640 system design. The last is about balancing the 1008 00:58:27,640 --> 00:58:29,120 coupling. Now you understand you have all 1009 00:58:29,120 --> 00:58:31,720 the tools and the knowledge required and your software 1010 00:58:31,720 --> 00:58:34,960 design, you advise us to actually know how to balance 1011 00:58:34,960 --> 00:58:37,440 this coupling when you make decisions in your software 1012 00:58:37,440 --> 00:58:39,560 architecture. Probably a little bit more 1013 00:58:39,720 --> 00:58:42,800 practical tips, right? Now that we know all this, how 1014 00:58:42,800 --> 00:58:44,960 would you advise us software engineers to think about 1015 00:58:44,960 --> 00:58:47,000 balancing coupling in our software design? 1016 00:58:47,760 --> 00:58:50,760 Yeah. So when you were making software 1017 00:58:50,760 --> 00:58:54,880 design decisions, at whatever level of abstraction, think 1018 00:58:54,880 --> 00:58:59,600 about those 3 dimensions. What is the knowledge that is 1019 00:58:59,600 --> 00:59:02,600 being shared? What is the distance across 1020 00:59:02,600 --> 00:59:04,520 which the knowledge is being shared? 1021 00:59:04,840 --> 00:59:08,440 And also, of course, what is the volatility of that knowledge is 1022 00:59:08,440 --> 00:59:10,520 going to be? How can you evaluate that 1023 00:59:10,560 --> 00:59:13,440 volatility? Well, that's a place where you 1024 00:59:13,440 --> 00:59:16,480 can use different models. I prefer domain driven design 1025 00:59:16,480 --> 00:59:18,960 subdomains, but there are other methods. 1026 00:59:19,600 --> 00:59:23,080 Now, my model of balanced coupling, it's not going to give 1027 00:59:23,080 --> 00:59:27,920 you a score like a number, like a grade that you can say, hey, I 1028 00:59:27,920 --> 00:59:30,840 implemented a system with 99% of balanced coupling. 1029 00:59:31,440 --> 00:59:35,080 Unfortunately not. Maybe somebody someday will join 1030 00:59:35,080 --> 00:59:39,080 forces and implement it, but the devil is in the details. 1031 00:59:39,920 --> 00:59:43,920 It's not something that is really trivial, but at the same 1032 00:59:43,920 --> 00:59:50,680 time I wanted to offer that model that you can keep in the 1033 00:59:50,680 --> 00:59:53,440 back of your head, something that is easy to remember, 1034 00:59:53,480 --> 00:59:58,560 something that doesn't require memorizing tons of different 1035 00:59:58,560 --> 01:00:00,920 patterns. All you have to remember is that 1036 01:00:00,920 --> 01:00:04,520 there are four types of knowledge, and that's basically, 1037 01:00:04,680 --> 01:00:08,720 and there are three dimensions. If you evaluate the knowledge 1038 01:00:08,920 --> 01:00:11,320 and you compare it with a distance, you know whether 1039 01:00:11,320 --> 01:00:13,720 you're headed towards modularity or complexity. 1040 01:00:14,240 --> 01:00:16,800 If you're headed towards complexity, then you can look at 1041 01:00:16,880 --> 01:00:21,160 the volatility and decide whether it's something that is 1042 01:00:21,240 --> 01:00:25,120 worth your effort or maybe you should focus on something else. 1043 01:00:25,720 --> 01:00:29,480 So overall, I would say keep these. 1044 01:00:29,960 --> 01:00:35,400 I hope that they are simple, these simple terms or ideas in 1045 01:00:35,400 --> 01:00:37,480 the back of your head when you're making software design 1046 01:00:37,480 --> 01:00:42,160 decisions and apply them. Again, it's not something that 1047 01:00:42,160 --> 01:00:45,240 is going to be easy to incorporate in continuous 1048 01:00:45,240 --> 01:00:48,680 integration pipeline, but it's something that is supposed to be 1049 01:00:48,680 --> 01:00:52,360 easy to incorporate in your software design decision making 1050 01:00:52,360 --> 01:00:54,000 process. Yeah. 1051 01:00:54,320 --> 01:00:57,120 So for different types of knowledge sharing, right, Just 1052 01:00:57,120 --> 01:00:59,920 to recap a little bit, there's an intrusive coupling, there's a 1053 01:00:59,920 --> 01:01:02,960 model coupling, functional coupling and so contract 1054 01:01:02,960 --> 01:01:05,240 coupling, right. So these four very important. 1055 01:01:05,240 --> 01:01:07,880 Maybe you should bring up these kind of terms when you discuss 1056 01:01:07,880 --> 01:01:10,800 collaboratively about your software design and then not 1057 01:01:10,800 --> 01:01:12,160 just about this knowledge sharing. 1058 01:01:12,200 --> 01:01:14,760 Because again, like coupling, probably the most problematic 1059 01:01:14,760 --> 01:01:15,920 one is about knowledge sharing, right? 1060 01:01:15,920 --> 01:01:17,840 The shared knowledge, the thing that we talked about in the 1061 01:01:17,840 --> 01:01:19,960 beginning. So after you analyze all this, 1062 01:01:20,120 --> 01:01:21,960 you also bring in the three different dimensions. 1063 01:01:21,960 --> 01:01:24,520 So integration strength is basically those four things, 1064 01:01:24,520 --> 01:01:25,960 right? And then you'll bring up the 1065 01:01:25,960 --> 01:01:29,000 topic about distance and also about the volatility. 1066 01:01:29,320 --> 01:01:33,000 So All in all, if you probably bring all these variables inside 1067 01:01:33,000 --> 01:01:35,560 your discussion, maybe you'll make a better decisions, right? 1068 01:01:35,920 --> 01:01:38,720 And also don't forget as well, maybe in the beginning you 1069 01:01:38,720 --> 01:01:42,400 design A better balance coupled system, but over the time as 1070 01:01:42,400 --> 01:01:45,160 because business change, you know software change which you 1071 01:01:45,160 --> 01:01:47,920 also covered in your book. There are so many reasons why 1072 01:01:47,920 --> 01:01:51,000 software will change, right? And let's not forget, when 1073 01:01:51,000 --> 01:01:54,480 something major change happen, you also bring up again this 1074 01:01:54,480 --> 01:01:57,880 topic to actually make sure that your change can rebalance your 1075 01:01:57,880 --> 01:01:59,600 software design in terms of coupling. 1076 01:01:59,920 --> 01:02:02,680 And also in the end, right, Eventually it doesn't create 1077 01:02:02,680 --> 01:02:05,920 like a big ball of mud or the worst case is distributed big 1078 01:02:05,920 --> 01:02:09,560 ball of mud, just like the crazy microservices that people are 1079 01:02:09,920 --> 01:02:12,520 struggling with. So I think All in all, these are 1080 01:02:12,560 --> 01:02:15,560 very good topics, right? For people who would like to 1081 01:02:15,600 --> 01:02:18,080 understand further, because I'm sure maybe just by listening, 1082 01:02:18,080 --> 01:02:20,200 this conversation is a little bit too short, right? 1083 01:02:20,320 --> 01:02:22,040 Maybe you should check out Let's book. 1084 01:02:22,040 --> 01:02:25,520 I think it's coming out soon and hopefully people will be better 1085 01:02:25,520 --> 01:02:28,760 to get a better tools, you know, like in terms of coming up with 1086 01:02:28,760 --> 01:02:31,320 better software design. So let's wrap up. 1087 01:02:31,400 --> 01:02:33,960 But before I let you go flat, I don't know whether you still 1088 01:02:33,960 --> 01:02:36,160 remember last time I asked you this question. 1089 01:02:36,480 --> 01:02:39,560 I asked you about these three technical leadership wisdom, I 1090 01:02:39,560 --> 01:02:43,120 think 2 years apart, right? And a new book as well. 1091 01:02:43,360 --> 01:02:46,480 Maybe if you can share a little bit of what kind of wisdom that 1092 01:02:46,480 --> 01:02:49,200 you can share with us, maybe with the theme of coupling. 1093 01:02:49,400 --> 01:02:51,960 So yeah, is there anything that you want to share with us? 1094 01:02:52,760 --> 01:02:56,600 Yes. So three tech leadership wisdom, 1095 01:02:57,360 --> 01:03:02,040 that's our question. But we started by discussing the 1096 01:03:02,040 --> 01:03:06,920 things that we kind of understand on the gut feeling 1097 01:03:06,920 --> 01:03:10,280 level. But it really, really helps to 1098 01:03:10,280 --> 01:03:14,600 get past that gut feeling level towards more explicit 1099 01:03:14,640 --> 01:03:18,640 definition. So if you stumble upon something 1100 01:03:18,640 --> 01:03:24,080 that you cannot explain clearly, I strongly recommend getting 1101 01:03:24,120 --> 01:03:28,600 into it, learning what's going on there because chances are you 1102 01:03:28,600 --> 01:03:32,000 are not alone. Usually there will be more 1103 01:03:32,000 --> 01:03:35,600 people struggling to define a concept. 1104 01:03:36,080 --> 01:03:38,800 For me it was, for example, coupling and modularity. 1105 01:03:38,840 --> 01:03:43,080 And once you are there, once you've found you were able to 1106 01:03:43,080 --> 01:03:47,880 find such term and to define it, then you should probably share 1107 01:03:47,880 --> 01:03:50,680 your wisdom with the world because people are going to be 1108 01:03:50,680 --> 01:03:54,280 grateful to you for doing that. So that was the first one. 1109 01:03:54,720 --> 01:03:58,320 And the second one would be about modelling. 1110 01:03:58,720 --> 01:04:04,760 So modelling is a very important part of what we're doing. 1111 01:04:05,280 --> 01:04:10,960 And as software engineers, I don't think we spend enough time 1112 01:04:11,160 --> 01:04:14,400 on training that muscle, that modelling muscle. 1113 01:04:14,720 --> 01:04:19,400 We spend more time doing workshops on Kubernetes and 1114 01:04:19,600 --> 01:04:23,720 Lambda functions, for example, things that are more technical. 1115 01:04:24,120 --> 01:04:28,840 Modelling is about our ability to understand the real world, 1116 01:04:28,920 --> 01:04:34,200 those real world systems that we have implemented in code. 1117 01:04:34,680 --> 01:04:40,160 So I would say bend time modelling, it's super important. 1118 01:04:40,160 --> 01:04:44,360 It's super important to train that muscle to get better at it. 1119 01:04:44,480 --> 01:04:49,560 And it also helps to analyse other models and models are 1120 01:04:49,560 --> 01:04:52,240 everywhere. Even if you are looking at a 1121 01:04:52,240 --> 01:04:57,600 model of toy car steel model. So think about analyse it from 1122 01:04:57,600 --> 01:05:00,880 that perspective. The model is not a copy of the 1123 01:05:00,880 --> 01:05:05,600 real world, it's human made contract that is supposed to 1124 01:05:05,600 --> 01:05:07,920 solve a problem. So ask yourself what is the 1125 01:05:07,920 --> 01:05:10,200 problem that this specific model solves? 1126 01:05:10,720 --> 01:05:13,720 Does it do a good job at it? If it's a toy car and then 1127 01:05:13,720 --> 01:05:18,960 probably it's goal is to mimic that possession of some cool 1128 01:05:18,960 --> 01:05:23,560 car, how cool is that etcetera with your software models. 1129 01:05:23,920 --> 01:05:28,200 And then of course, apply that knowledge for evaluating what I 1130 01:05:28,200 --> 01:05:31,480 called earlier models of models, integration contracts. 1131 01:05:31,480 --> 01:05:34,560 How effective are they of encapsulating knowledge? 1132 01:05:34,880 --> 01:05:39,520 And that will help you to become a much better software designer. 1133 01:05:39,720 --> 01:05:43,040 Again, at whatever level of abstraction you're working on, 1134 01:05:43,040 --> 01:05:45,800 it doesn't matter. The underlying ideas are the 1135 01:05:45,800 --> 01:05:50,120 same. And that brings me to the third 1136 01:05:50,480 --> 01:05:55,000 tech leadership wisdom. And that would be about design. 1137 01:05:55,560 --> 01:06:00,960 And design is another overloaded term that different people 1138 01:06:00,960 --> 01:06:04,320 understand in different ways. We have graphical design, we 1139 01:06:04,320 --> 01:06:08,280 have software design, we have product design, whatever. 1140 01:06:08,400 --> 01:06:11,920 But if you ask yourself about what's the purpose of design, 1141 01:06:11,920 --> 01:06:13,520 it's usually to solve the problem. 1142 01:06:13,760 --> 01:06:19,400 The design is of a solution. So again, getting better at the 1143 01:06:19,400 --> 01:06:22,760 design, it's like getting better at modelling, but at a different 1144 01:06:22,760 --> 01:06:25,600 level of abstraction. Evaluate designs. 1145 01:06:25,960 --> 01:06:29,800 Let's say you're looking at the microphone I'm using right now. 1146 01:06:30,080 --> 01:06:33,000 What about it's design? Is it good or bad? 1147 01:06:34,000 --> 01:06:37,080 This mute button which is impossible to reach, is it good? 1148 01:06:37,400 --> 01:06:40,800 Does it solve the problem or should I keep my app open on the 1149 01:06:40,800 --> 01:06:43,280 screen all the time? Probably that says something 1150 01:06:43,280 --> 01:06:47,440 about the design. And once you're will get into 1151 01:06:47,440 --> 01:06:52,600 that notion of design and again design of whatever from 1152 01:06:52,920 --> 01:06:57,520 appliances to software underneath, usually there are 1153 01:06:57,520 --> 01:07:01,920 the same principles that are driving that design being good 1154 01:07:01,920 --> 01:07:05,800 or bad. And usually there will be some 1155 01:07:05,800 --> 01:07:11,480 representation of distance and knowledge in software design. 1156 01:07:11,480 --> 01:07:14,920 As I said, we have a integration strength and distance and 1157 01:07:14,920 --> 01:07:18,720 balance and graphical design. For example, you have sizes of 1158 01:07:18,720 --> 01:07:21,560 components on the web page. The greater the distance, the 1159 01:07:21,560 --> 01:07:23,000 bigger should be the size, right? 1160 01:07:23,440 --> 01:07:26,320 The greater the the distance that your mouse travels. 1161 01:07:26,800 --> 01:07:30,680 So yeah, these are the topics that are sort of philosophical, 1162 01:07:30,680 --> 01:07:34,520 but underneath they will definitely make you a much 1163 01:07:34,520 --> 01:07:38,640 better software architect, software designer, or just 1164 01:07:38,640 --> 01:07:40,640 software engineer. That's what I call myself. 1165 01:07:41,880 --> 01:07:44,480 Right, I really love this meta with them, right. 1166 01:07:44,480 --> 01:07:47,280 So you kind of like will bring up a topic that is a quite high 1167 01:07:47,280 --> 01:07:49,760 level. I like the term model of model 1168 01:07:49,760 --> 01:07:51,600 actually. So it explains about the 1169 01:07:51,600 --> 01:07:53,240 contract really, really well, right? 1170 01:07:53,240 --> 01:07:55,680 So you have a model and then you come up with another model to 1171 01:07:55,680 --> 01:07:59,320 actually exchange the knowledge or information between maybe two 1172 01:07:59,320 --> 01:08:00,760 components or two services, right? 1173 01:08:01,120 --> 01:08:03,840 So flat, it's a pleasure to actually discuss with you about 1174 01:08:03,840 --> 01:08:05,600 this topic. I think coupling is something 1175 01:08:05,600 --> 01:08:07,880 that we all software engineers really, really need to 1176 01:08:07,880 --> 01:08:10,080 understand well. And I find that in many software 1177 01:08:10,080 --> 01:08:12,840 engineers, when we talk about software design and this is less 1178 01:08:13,000 --> 01:08:16,319 included in the design, simply because we talk about 1179 01:08:16,920 --> 01:08:20,040 architecture patterns, probably technologies, right, or maybe 1180 01:08:20,040 --> 01:08:22,720 called technologies, Kubernetes and things like that. 1181 01:08:23,000 --> 01:08:25,600 But actually talking about coupling, modularity, 1182 01:08:25,600 --> 01:08:28,560 complexity, knowledge, boundaries and things like that 1183 01:08:28,560 --> 01:08:30,960 is very little in the discussion. 1184 01:08:31,439 --> 01:08:34,160 So I hope people are more well equipped now with the book, 1185 01:08:34,160 --> 01:08:36,560 right? And for people who love to maybe 1186 01:08:36,560 --> 01:08:39,359 ask you questions, maybe continue discussion or maybe 1187 01:08:39,359 --> 01:08:41,080 just find out more about this topic. 1188 01:08:41,319 --> 01:08:44,640 Is there a place where they can find such resources online? 1189 01:08:45,359 --> 01:08:48,080 Yeah, so you can find me on Twitter. 1190 01:08:48,080 --> 01:08:51,160 You can find me on LinkedIn. I assume the links are going to 1191 01:08:51,160 --> 01:08:53,680 be in the show notes. I have a blog, which looks like 1192 01:08:53,680 --> 01:08:58,279 a very sad place right now because, yeah, I didn't have 1193 01:08:58,279 --> 01:09:02,479 time to update it. And every month somebody, some 1194 01:09:02,479 --> 01:09:06,040 nice person, emails me saying that a link on your blog is 1195 01:09:06,040 --> 01:09:10,080 broken and I promise to fix it. But here we are. 1196 01:09:10,640 --> 01:09:14,640 So yeah, I would say Twitter and LinkedIn, these are the places 1197 01:09:14,640 --> 01:09:17,479 to get news. The Coupling book supposed to be 1198 01:09:17,479 --> 01:09:23,319 published in September 24. At the moment it's available on 1199 01:09:23,319 --> 01:09:25,160 O'Reilly online learning platform. 1200 01:09:25,640 --> 01:09:29,960 That draft is probably the same one that's going to be 1201 01:09:29,960 --> 01:09:34,160 published, just improved with professional copy editing and 1202 01:09:34,160 --> 01:09:37,920 professional illustrations. And yeah, also there are going 1203 01:09:37,920 --> 01:09:40,439 to be a summary chapter, but that's about it. 1204 01:09:41,279 --> 01:09:43,399 Right, So I really highly recommend the book, right? 1205 01:09:43,399 --> 01:09:45,560 So I think you can also check it out on O'Reilly. 1206 01:09:45,560 --> 01:09:47,960 I read it as part of this preparation, right? 1207 01:09:47,960 --> 01:09:50,479 So I think it's pretty much robust and complete, I would 1208 01:09:50,479 --> 01:09:53,279 say, in terms of content. So yeah, I think good luck with 1209 01:09:53,279 --> 01:09:56,040 your publication. So hopefully people can get to 1210 01:09:56,040 --> 01:09:57,840 understand about this concept much better. 1211 01:09:57,840 --> 01:09:59,360 So thanks again for your time flat. 1212 01:10:00,080 --> 01:10:02,400 Thank you so much, Henry. It's been a pleasure.