1 00:00:00,040 --> 00:00:02,880 I think it's expected that every software gets more complex over 2 00:00:02,880 --> 00:00:04,360 time. And I think what we need to do 3 00:00:04,360 --> 00:00:08,600 as engineers is to find ways so that we can keep increasing 4 00:00:08,800 --> 00:00:12,920 complexity but not increasing the cost of maintaining this 5 00:00:12,920 --> 00:00:15,880 software. Sometimes people try to say that 6 00:00:15,880 --> 00:00:18,320 you should, you know, find a way so that software never grows in 7 00:00:18,320 --> 00:00:20,240 complexity. I don't believe that that is 8 00:00:20,240 --> 00:00:22,360 really possible. Do you think it's indeed the 9 00:00:22,360 --> 00:00:24,720 other way around? You have to just live with the 10 00:00:24,720 --> 00:00:26,960 fact that it will get more complex. 11 00:00:31,880 --> 00:00:37,080 Hey everyone, my name is Henry Surya Virawan, and you're 12 00:00:37,080 --> 00:00:40,640 listening to the Technically Journal Podcast, the show where 13 00:00:40,640 --> 00:00:42,880 I'll be bringing you the greatest technical leaders, 14 00:00:43,160 --> 00:00:46,720 practitioners, and thought leaders in the industry to 15 00:00:46,720 --> 00:00:50,960 discuss about their journey, ideas, and practices that we all 16 00:00:50,960 --> 00:00:54,480 can learn and apply to build a highly performing technical team 17 00:00:55,000 --> 00:00:57,200 and to make an impact in your personal work. 18 00:00:57,840 --> 00:01:06,160 So let's dive into our journal. Hello, everyone, welcome back to 19 00:01:06,160 --> 00:01:08,480 another new episode of the Technically Journal Podcast. 20 00:01:08,480 --> 00:01:12,760 Today I have a repeat guest, so Mauricio Anish, he was in 21 00:01:12,760 --> 00:01:16,400 episode 139, so almost one year ago. 22 00:01:16,640 --> 00:01:20,360 Today he's back with his new book, Simple Object Oriented 23 00:01:20,360 --> 00:01:22,760 Design. So today we'll talk about 24 00:01:22,760 --> 00:01:26,040 software complexity, object oriented programming, and what 25 00:01:26,040 --> 00:01:29,600 kind of design that Mauricio is advocating so that we can 26 00:01:29,600 --> 00:01:32,680 maintain the complexity of all software and make sure that the 27 00:01:32,680 --> 00:01:36,160 design performs well and we can always maintain the software. 28 00:01:36,480 --> 00:01:38,840 So welcome back Mauricio to our show. 29 00:01:39,080 --> 00:01:41,400 So looking forward for this conversation. 30 00:01:42,120 --> 00:01:43,920 Thanks, Harry, It's a pleasure to be back. 31 00:01:44,840 --> 00:01:48,520 Right, Mauricio, So it's been almost a year since we last chat 32 00:01:48,520 --> 00:01:50,600 with each other. So maybe if you can give us a 33 00:01:50,600 --> 00:01:53,400 glimpse what you were up to in the past one year? 34 00:01:54,040 --> 00:01:56,560 For sure. So for those that didn't listen 35 00:01:56,560 --> 00:01:58,480 to the previous one, my name is Mauricio. 36 00:01:58,920 --> 00:02:02,040 I work in the software industry. For 20 years I've been a 37 00:02:02,040 --> 00:02:04,560 developer, I've been a full time researcher. 38 00:02:04,840 --> 00:02:08,280 Now I'm back to industry and in the past 2 1/2 years I work for 39 00:02:08,280 --> 00:02:11,520 Ajin. Ajin is a financial technology 40 00:02:11,520 --> 00:02:16,280 company and right now my current duties are to lead the team that 41 00:02:16,280 --> 00:02:21,040 we call testing enablement team. We do basically tools that help 42 00:02:21,040 --> 00:02:25,240 developers to create tests. We do code quality related tools 43 00:02:25,720 --> 00:02:28,520 and this type of stuff. So yeah, that's this is what I'm 44 00:02:28,520 --> 00:02:31,680 up to. Hey, thank you for being part of 45 00:02:31,680 --> 00:02:33,120 the technically journal community. 46 00:02:33,480 --> 00:02:36,720 This show wouldn't be the same without your ears and you are 47 00:02:36,720 --> 00:02:41,040 the reason this show exists. If you're loving TLJ and want to 48 00:02:41,040 --> 00:02:44,280 see it keep on growing, consider becoming a patron at 49 00:02:44,280 --> 00:02:48,200 Techledjournal dot dev Patron or buying me a coffee at 50 00:02:48,200 --> 00:02:53,040 Techledjournal dot dev coffee. Every little bit helps field the 51 00:02:53,040 --> 00:02:56,640 research, editing and sleepless nights that go into making this 52 00:02:56,640 --> 00:02:59,840 show the best it can be. Thanks for being the best 53 00:02:59,840 --> 00:03:02,040 listeners any podcast could ask for. 54 00:03:02,440 --> 00:03:04,360 And now let's get back to our episode. 55 00:03:04,680 --> 00:03:06,600 Yeah. So I think for those of you who 56 00:03:06,600 --> 00:03:09,840 haven't listened to the previous episode by Mauritio, right, we 57 00:03:09,840 --> 00:03:12,520 talk a lot about testing, effective testing in fact. 58 00:03:12,920 --> 00:03:15,120 So there are a lot of insights. I learned a lot from that 59 00:03:15,120 --> 00:03:16,760 episode. So make sure to check it out as 60 00:03:16,760 --> 00:03:18,840 well if you haven't listened to that episode. 61 00:03:19,320 --> 00:03:22,600 So today we'll be talking about your new new book, Simple Object 62 00:03:22,600 --> 00:03:24,840 Oriented Design. So maybe in the beginning 63 00:03:24,920 --> 00:03:27,240 explain to us like why you came up with this book. 64 00:03:27,280 --> 00:03:29,720 It seems like a little bit different from the first book 65 00:03:29,720 --> 00:03:32,440 that you wrote a few years ago. For sure. 66 00:03:32,800 --> 00:03:34,320 And actually, I just got a copy here. 67 00:03:34,320 --> 00:03:37,520 So if you're watching the video, you can see the beautiful cover 68 00:03:37,520 --> 00:03:39,520 that Manny has prepared for this one. 69 00:03:40,040 --> 00:03:43,040 And I think the motivation for this book was that one of my 70 00:03:43,040 --> 00:03:47,640 best friends, Alberto, him and I, we always talk about code 71 00:03:47,640 --> 00:03:50,760 design, right? How to design classes so that 72 00:03:50,760 --> 00:03:54,280 you can implement your business focus system in in a nice way. 73 00:03:54,280 --> 00:03:57,080 And Alberto loves design and we talk a lot about it. 74 00:03:57,560 --> 00:04:00,800 And all those conversations, they triggered me and I felt 75 00:04:01,120 --> 00:04:04,240 maybe I should just, you know, try to write down the best 76 00:04:04,240 --> 00:04:08,120 practices I observed throughout my career and hopefully in a 77 00:04:08,120 --> 00:04:11,160 very short and concise way. So this book is quite short. 78 00:04:11,160 --> 00:04:14,760 I think 150 pages is the final printed version. 79 00:04:15,160 --> 00:04:16,760 So that's how this book came to be. 80 00:04:16,760 --> 00:04:20,480 And I think one of the premises that I had there was that I went 81 00:04:20,480 --> 00:04:25,000 in a book that doesn't strive for the perfect design, right? 82 00:04:25,040 --> 00:04:27,200 Because it feels like to me, sometimes I read a book about 83 00:04:27,200 --> 00:04:29,640 objectory and the design, and the design is perfect. 84 00:04:29,640 --> 00:04:32,480 And that assumes that the person knows a lot about the problem 85 00:04:32,480 --> 00:04:34,560 already. And that's not what happens in 86 00:04:34,560 --> 00:04:37,600 real life, right? You get a very messy requirement 87 00:04:37,600 --> 00:04:39,760 that you don't know so much about it that is going to 88 00:04:39,760 --> 00:04:42,320 change. And you cannot go for the best 89 00:04:42,320 --> 00:04:44,680 design ever. So you have to take pragmatic 90 00:04:44,680 --> 00:04:47,320 decision so that you can move forward and deliver softer. 91 00:04:47,640 --> 00:04:50,360 So that's what I wanted to try to summarize in this book. 92 00:04:51,040 --> 00:04:54,000 So you mentioned that, I mean your career 20 years, right? 93 00:04:54,000 --> 00:04:57,640 So you opened the book by saying that after 20 years being in the 94 00:04:57,640 --> 00:05:01,080 industry previously, you try to achieve perfection, you know, 95 00:05:01,080 --> 00:05:04,640 maybe perfect code design, but you currently don't believe that 96 00:05:04,640 --> 00:05:07,520 it is true anymore, right? So you think that probably 97 00:05:07,520 --> 00:05:08,960 there's no perfect software out there. 98 00:05:09,240 --> 00:05:12,760 So tell us your revelation about this, and maybe what we can 99 00:05:12,760 --> 00:05:14,440 learn from that revelation as well. 100 00:05:15,080 --> 00:05:17,840 Yeah, for sure. I think for me, it was when I 101 00:05:17,840 --> 00:05:21,600 learned Objectory entered design more than 10 years ago, I 102 00:05:21,680 --> 00:05:24,320 thought this was just beautiful. You know, they could create 103 00:05:24,320 --> 00:05:27,640 objects and they could talk to each other and then if you 104 00:05:27,640 --> 00:05:31,000 really do your best, then those objects, they just look so 105 00:05:31,000 --> 00:05:34,800 pretty and so elegant. But in real life, life is way 106 00:05:34,800 --> 00:05:37,840 more messy than the examples you see in books and things change 107 00:05:37,840 --> 00:05:41,680 in real life and etcetera. So I feel like it's, and I think 108 00:05:41,680 --> 00:05:43,960 in my 20 years of experience, although right now I don't like 109 00:05:43,960 --> 00:05:46,080 business logic, right? So I mean platform engineering. 110 00:05:46,080 --> 00:05:47,800 So I'm more writing tools for developers. 111 00:05:48,160 --> 00:05:50,800 But in my previous experiences, I was always, you know, a back 112 00:05:50,800 --> 00:05:52,960 end developer implementing business rules. 113 00:05:53,360 --> 00:05:56,880 I guess like a lot of the people out there, it was never possible 114 00:05:56,880 --> 00:06:00,040 to achieve perfection, right? We always had to, you know, at 115 00:06:00,040 --> 00:06:03,240 some point settle for something and and we should be OK with 116 00:06:03,240 --> 00:06:04,760 that because that's just life, right? 117 00:06:04,760 --> 00:06:07,800 So we don't want to take the most awful decision possible, 118 00:06:07,800 --> 00:06:09,080 right? Because it's really bad. 119 00:06:09,080 --> 00:06:11,880 That creates technical debt. But you also don't have to 120 00:06:11,880 --> 00:06:14,080 strive for perfection. Something in between is good 121 00:06:14,080 --> 00:06:15,400 enough. Yeah. 122 00:06:15,400 --> 00:06:18,440 So I think over in my career as well, especially when we work 123 00:06:18,440 --> 00:06:21,040 with multiple people in the teams, right, with various 124 00:06:21,040 --> 00:06:24,160 degree of experience. So I think it's really hard to 125 00:06:24,160 --> 00:06:27,480 maintain quality across everyone, right. 126 00:06:27,480 --> 00:06:30,920 So sometimes we have to let go some parts of it, but as long as 127 00:06:30,920 --> 00:06:34,840 the maybe general high level design is good, we can always 128 00:06:35,040 --> 00:06:37,640 maintain and maybe refactor from time to time, right? 129 00:06:37,840 --> 00:06:40,680 Which brings me to the next discussion about software 130 00:06:40,680 --> 00:06:43,320 complexity. So I think it's very funny. 131 00:06:43,360 --> 00:06:46,680 I mean, we all have been there. We try to build a new system 132 00:06:46,680 --> 00:06:49,080 right from scratch. We think that this is going to 133 00:06:49,080 --> 00:06:51,760 be different this time, right? So we'll build a perfect 134 00:06:51,760 --> 00:06:56,040 software, but I think over the time software gets complex and 135 00:06:56,040 --> 00:06:59,560 again we come to the same cycle that software is becoming quite 136 00:06:59,560 --> 00:07:03,200 complicated to change. So why software can become 137 00:07:03,200 --> 00:07:06,760 complex over time and what we should do in order to maintain 138 00:07:06,760 --> 00:07:08,480 that? Yeah, for sure. 139 00:07:08,960 --> 00:07:12,440 So software becomes complex just because lives gets more complex, 140 00:07:12,880 --> 00:07:14,080 right? So we're sort of trying to 141 00:07:14,080 --> 00:07:16,640 implement software to solve people's problems, but those 142 00:07:16,640 --> 00:07:19,680 problems get more complex. And if you don't pay attention, 143 00:07:19,680 --> 00:07:22,480 your code will also get complex. And that's natural. 144 00:07:22,920 --> 00:07:25,800 I think it's expected that every software gets more complex over 145 00:07:25,800 --> 00:07:27,280 time. And I think what we need to do 146 00:07:27,280 --> 00:07:31,560 as engineers is to find ways so that we can keep increasing 147 00:07:31,760 --> 00:07:35,840 complexity but not increasing the cost of maintaining this 148 00:07:35,840 --> 00:07:38,840 software. Sometimes people try to say that 149 00:07:38,840 --> 00:07:41,240 you should, you know, find a way so that software never grows in 150 00:07:41,240 --> 00:07:43,200 complexity. I don't believe that that is 151 00:07:43,200 --> 00:07:45,320 really possible. Do you think it's indeed the 152 00:07:45,320 --> 00:07:47,680 other way around? You have to just live with the 153 00:07:47,680 --> 00:07:49,920 fact that it will get more complex. 154 00:07:50,600 --> 00:07:53,520 Yeah, especially as you keep on building on top of what 155 00:07:53,520 --> 00:07:56,240 existing, right. So I think more business logic, 156 00:07:56,480 --> 00:07:59,400 maybe new features, right, sometimes edge cases that you 157 00:07:59,400 --> 00:08:03,040 didn't think before and somehow it gets introduced, but it just 158 00:08:03,040 --> 00:08:06,040 doesn't fit rightly, right. So in order to make it quick, so 159 00:08:06,040 --> 00:08:08,480 you just add as quickly as possible as well. 160 00:08:08,760 --> 00:08:11,560 So I think I do agree especially for business related software, 161 00:08:11,560 --> 00:08:13,320 right? I think it tends to get 162 00:08:13,320 --> 00:08:15,360 complicated especially these days. 163 00:08:15,360 --> 00:08:17,600 People also over complicate the architecture, right. 164 00:08:17,600 --> 00:08:20,920 So maybe using micro services or maybe different databases and 165 00:08:20,920 --> 00:08:23,000 things like that. I think it makes the software 166 00:08:23,000 --> 00:08:26,680 get more complicated as well. So I think another thing that I 167 00:08:26,720 --> 00:08:29,880 am interested in your book you cover object oriented design. 168 00:08:29,880 --> 00:08:32,840 I think these days many people kind of like have different 169 00:08:32,840 --> 00:08:34,360 flavour of programming languages. 170 00:08:34,640 --> 00:08:36,919 Object oriented design and functional programming probably 171 00:08:36,919 --> 00:08:40,039 are the two biggest. So maybe your view is object 172 00:08:40,039 --> 00:08:43,120 oriented still relevant? Or should people think about 173 00:08:43,120 --> 00:08:44,880 some kind of different paradigms? 174 00:08:45,520 --> 00:08:48,240 I think all those paradigms are good enough and you can build 175 00:08:48,240 --> 00:08:50,160 good software with all of them, right? 176 00:08:50,160 --> 00:08:52,960 The functional programming, data oriented programming that is 177 00:08:52,960 --> 00:08:56,880 getting more traction right now, I feel it's just about picking 178 00:08:56,880 --> 00:08:58,760 the the paradigm that works best for you. 179 00:08:59,400 --> 00:09:03,240 And for me, object oriented programming was always the one 180 00:09:03,240 --> 00:09:05,680 that my mind could understand better. 181 00:09:06,080 --> 00:09:07,680 So I don't think it's a bad decision. 182 00:09:07,960 --> 00:09:10,600 I think if we start a project today using object oriented 183 00:09:10,600 --> 00:09:12,320 programming, it is a good choice. 184 00:09:12,320 --> 00:09:15,480 You will be able to write maintainable software for sure. 185 00:09:16,160 --> 00:09:18,080 Yeah. So I think you mentioned as well 186 00:09:18,080 --> 00:09:20,520 in your book that object oriented helps you to build 187 00:09:20,520 --> 00:09:22,880 maintainable software, of course, if done right. 188 00:09:22,960 --> 00:09:26,360 But I think, yeah, it's also a very nice abstraction in a way, 189 00:09:26,360 --> 00:09:28,120 right? So you can kind of like thinking 190 00:09:28,160 --> 00:09:30,480 objects, right? So some people find it more 191 00:09:30,480 --> 00:09:32,440 intuitive. I do find it more intuitive as 192 00:09:32,440 --> 00:09:34,440 well, but I think different kind of problems. 193 00:09:34,440 --> 00:09:37,360 Also sometimes you can choose different programming paradigms 194 00:09:37,360 --> 00:09:40,720 which may be more suitable. For example, maybe data pipeline 195 00:09:40,720 --> 00:09:43,520 kind of thing is more suitable for functional programming. 196 00:09:43,800 --> 00:09:46,800 So yeah, let's probably cover the object oriented part this 197 00:09:46,800 --> 00:09:49,160 time. You mentioned that we always 198 00:09:49,160 --> 00:09:54,200 have to keep design as part of our activity in software 199 00:09:54,200 --> 00:09:57,040 development. So I think it this is probably 200 00:09:57,440 --> 00:10:00,680 intuitive in a sense, but not practiced a lot by different 201 00:10:00,680 --> 00:10:04,000 people because they assume that the design is there, I just need 202 00:10:04,000 --> 00:10:06,320 to add on top of what exists, right? 203 00:10:06,640 --> 00:10:09,640 So tell us, how can we do more design activities in our 204 00:10:09,640 --> 00:10:12,400 software development? For me, one of the greatest 205 00:10:12,400 --> 00:10:14,640 powers in object oriented programming is that you can 206 00:10:14,640 --> 00:10:17,320 create abstractions and then abstractions. 207 00:10:17,360 --> 00:10:19,800 They reduce the complexity because suddenly you don't have 208 00:10:19,800 --> 00:10:23,200 to handle specific implementation details, you just 209 00:10:23,200 --> 00:10:25,200 focus on the abstraction. Those abstractions are more 210 00:10:25,200 --> 00:10:27,600 extensible. They provide usually extension 211 00:10:27,600 --> 00:10:30,480 points, so one and so forth. So object oriented programming 212 00:10:30,480 --> 00:10:35,000 can be very powerful if you're always thinking of how to make 213 00:10:35,000 --> 00:10:37,120 sure I'm building the right abstractions. 214 00:10:37,440 --> 00:10:39,840 And when I say you have to always be developing with this 215 00:10:40,040 --> 00:10:42,520 designing minds, it is because if you don't think of 216 00:10:42,520 --> 00:10:45,840 abstraction, then you know, how should my classes look like, 217 00:10:45,880 --> 00:10:48,080 what should be my extension point, so on and so forth. 218 00:10:48,480 --> 00:10:50,120 You know, you're just going to go to the code, then you're 219 00:10:50,120 --> 00:10:52,000 going to just write the implementation that solves the 220 00:10:52,000 --> 00:10:54,240 problem. Then let's say maybe this is, 221 00:10:54,240 --> 00:10:56,920 you know, 10 ifs in a row that solves the problem for sure. 222 00:10:56,920 --> 00:11:00,720 But this is maintainable. And when you have the design in 223 00:11:00,720 --> 00:11:04,120 mind, you're like, oh, OK, it feels like those I have to 224 00:11:04,120 --> 00:11:07,200 implement those ten different business rules and 10 if 225 00:11:07,200 --> 00:11:10,080 statements are the easiest possible way for me to do this. 226 00:11:10,080 --> 00:11:12,840 But this is good design. Is this going to help me in 227 00:11:12,840 --> 00:11:15,760 maintaining this in the future, in testing this and evolving 228 00:11:15,760 --> 00:11:17,640 this? And if you make this into a 229 00:11:17,640 --> 00:11:20,000 day-to-day activity, it hurts you less. 230 00:11:20,320 --> 00:11:23,080 And you mentioned when you're talking about my previous 231 00:11:23,080 --> 00:11:25,520 comment that you know you're designing something and then you 232 00:11:25,520 --> 00:11:28,080 have corner cases and etcetera. And those things really hurt 233 00:11:28,160 --> 00:11:30,280 your abstractions, right? That's the real life I want to 234 00:11:30,280 --> 00:11:32,760 bring into this book, right? That you create this beautiful 235 00:11:32,760 --> 00:11:34,240 abstraction. It seems like it works. 236 00:11:34,240 --> 00:11:36,440 You deploy and then suddenly you find a corner case that your 237 00:11:36,440 --> 00:11:39,360 abstraction doesn't fit. And that's just normal. 238 00:11:39,800 --> 00:11:42,440 But then once you've come back, you have to know, has your 239 00:11:42,440 --> 00:11:45,080 design mind set in mind and do I need to improve my design? 240 00:11:45,080 --> 00:11:47,840 Or if I just add this if statement here, is this like a 241 00:11:47,840 --> 00:11:49,760 huge sin that I'm making right now? 242 00:11:50,400 --> 00:11:54,920 So as long as you have you're always thinking of the design, I 243 00:11:54,920 --> 00:11:56,880 think you're fine. If you're not thinking of 244 00:11:56,880 --> 00:11:59,640 designing, just coding, then I think then you're not really 245 00:11:59,720 --> 00:12:02,560 using the power of object oriented programming. 246 00:12:03,360 --> 00:12:05,800 So I think that's really, really insightful, right? 247 00:12:05,800 --> 00:12:09,720 So think about abstractions and always try to look back whether 248 00:12:09,720 --> 00:12:12,880 the existing abstraction or design actually fits the problem 249 00:12:12,880 --> 00:12:15,080 as it evolves. And I think you also quoted 250 00:12:15,080 --> 00:12:18,520 multiple times in the book, right, John Osterhalt And one of 251 00:12:18,520 --> 00:12:21,720 the quote is actually talking about effective design actually 252 00:12:21,720 --> 00:12:24,160 comes up after multiple iterations, right? 253 00:12:24,200 --> 00:12:27,600 After maybe one or two or three times you work on the same 254 00:12:27,600 --> 00:12:29,840 problem, right? And somehow you find the right 255 00:12:29,840 --> 00:12:32,840 design afterwards. So I think what I can see in 256 00:12:32,840 --> 00:12:35,880 practice in the real world is that sometimes we come up with 257 00:12:35,880 --> 00:12:39,320 first design, have few problems along the way, but we didn't 258 00:12:39,320 --> 00:12:42,760 actually refactor or redesign and we just built on top of it 259 00:12:42,840 --> 00:12:46,840 until it gets so complicated that we probably think of, you 260 00:12:46,840 --> 00:12:50,880 know, we should rewrite this. So tell us, how can we actually 261 00:12:51,120 --> 00:12:55,000 have more dare to actually do a lot of redesigns throughout all 262 00:12:55,000 --> 00:12:57,160 the software development? Indeed. 263 00:12:57,160 --> 00:12:58,880 So that book influenced me a lot. 264 00:12:59,040 --> 00:13:01,280 It's a book that I read much later in my career because it's 265 00:13:01,280 --> 00:13:05,360 more of a recent book, right? But it has so many good gems 266 00:13:05,360 --> 00:13:09,080 that I really loved. And although I don't agree 100% 267 00:13:09,080 --> 00:13:11,200 with that book, right, I think I even write this in my book that 268 00:13:11,200 --> 00:13:13,720 there are some parts that I don't believe, but he does 269 00:13:13,720 --> 00:13:18,000 mention that in his experience, he only gets to be perfect 270 00:13:18,240 --> 00:13:22,280 between coats design after the third time he's working on that 271 00:13:22,280 --> 00:13:24,200 problem, right? So you try once, then you learn 272 00:13:24,200 --> 00:13:26,520 something, you try the second time, you learn more, the third 273 00:13:26,520 --> 00:13:29,880 one looks a little bit better. And when I read that paragraphs 274 00:13:29,880 --> 00:13:32,120 in the book, I was like, yes, that makes a lot of sense. 275 00:13:32,120 --> 00:13:34,240 I feel like for all the things that I did something really 276 00:13:34,320 --> 00:13:37,600 beautiful and elegant and flexible, it was because I 277 00:13:37,600 --> 00:13:39,520 already knew the problem for so long. 278 00:13:39,920 --> 00:13:43,800 Then I had tried already my first POC and you know, there 279 00:13:43,800 --> 00:13:47,720 was a realization for me that you will never do something in 280 00:13:47,720 --> 00:13:50,360 your first shop that really looks elegant in the way you 281 00:13:50,360 --> 00:13:52,400 want. That then leads me to the 282 00:13:52,400 --> 00:13:55,640 argument of my book that is if you know that's just what's 283 00:13:55,640 --> 00:13:58,400 going to happen, you are not going to come up with something 284 00:13:58,640 --> 00:14:01,560 elegant from the first try. You have to keep monitoring 285 00:14:01,560 --> 00:14:04,200 yourself and as soon as you learn a little bit more than you 286 00:14:04,200 --> 00:14:06,880 have to invest in refactoring these and improving it. 287 00:14:07,320 --> 00:14:09,640 Because if you do these at the very beginning, odds are then 288 00:14:09,640 --> 00:14:13,160 it's cheaper than doing this five years later where the code 289 00:14:13,160 --> 00:14:15,840 base is much bigger, everything is much bigger. 290 00:14:16,240 --> 00:14:19,680 So I feel like putting refactoring on the loop and not 291 00:14:19,680 --> 00:14:22,760 being ashamed of, you know, let me change a design decision that 292 00:14:22,760 --> 00:14:25,560 I took because like 3 months ago, but it is already a wrong 293 00:14:25,560 --> 00:14:27,640 decision. Maybe it's cheaper than if you 294 00:14:28,120 --> 00:14:29,880 do it later. So that that's sort of the the 295 00:14:29,880 --> 00:14:32,200 argument I I make there. Right. 296 00:14:32,240 --> 00:14:35,480 So I think refactoring is always some things that it takes 297 00:14:35,480 --> 00:14:37,840 discipline, right? So from every developer to 298 00:14:37,880 --> 00:14:42,120 actually have the, you know, optimism to continuously doing 299 00:14:42,120 --> 00:14:44,320 it, also having effective testing. 300 00:14:44,320 --> 00:14:47,280 So it's very important because when you refactor, you don't 301 00:14:47,280 --> 00:14:50,440 want to break previous features or have some regression box. 302 00:14:50,880 --> 00:14:53,880 And I think importantly as well, like use different kind of tools 303 00:14:53,880 --> 00:14:57,480 to help you in the refactoring. Maybe use the modern ID ES, 304 00:14:57,480 --> 00:14:59,360 right? Or maybe use AI these days. 305 00:14:59,400 --> 00:15:02,200 They can help you explain the code and maybe do kind of like a 306 00:15:02,200 --> 00:15:05,800 local optimization. So all these things should help 307 00:15:05,800 --> 00:15:09,560 you to support your refactoring activity and hopefully the good 308 00:15:09,560 --> 00:15:12,920 design can come up from there. Yes, I was going to say tooling 309 00:15:12,920 --> 00:15:15,440 is important, knowledge is important, but also culture, 310 00:15:15,760 --> 00:15:18,040 because I've been to teams, every factoring was just part of 311 00:15:18,040 --> 00:15:20,280 the culture and people would really appreciate when they're 312 00:15:20,280 --> 00:15:22,560 doing this type of commits in the codebase, right. 313 00:15:22,560 --> 00:15:27,320 But I've also been to teams where this was so as you know, 314 00:15:27,480 --> 00:15:29,560 as a bad thing, you know, like you're not being productive, 315 00:15:29,560 --> 00:15:31,880 you're not really delivering business rules, new 316 00:15:31,880 --> 00:15:35,000 functionality and etcetera. So I think culture is also a big 317 00:15:35,000 --> 00:15:37,360 part of how we make it possible. If you're in a culture where 318 00:15:37,360 --> 00:15:41,320 refactoring's well seen, then lucky you just do it right. 319 00:15:41,840 --> 00:15:44,840 If you're not, then maybe you should first change the culture 320 00:15:44,840 --> 00:15:47,760 rather than trying to introduce new tools or knowledge sharing 321 00:15:47,760 --> 00:15:49,440 sessions because they will not be enough. 322 00:15:50,160 --> 00:15:52,440 Yeah, I think that's a very good pointer, right? 323 00:15:52,440 --> 00:15:54,240 So culture is very important indeed. 324 00:15:54,240 --> 00:15:58,000 So sometimes developers may be afraid to say, I am refactoring 325 00:15:58,240 --> 00:16:00,240 this design because it wasn't right. 326 00:16:00,560 --> 00:16:03,840 So people may think, OK, why didn't you do it right in the 327 00:16:03,840 --> 00:16:05,760 first time? So I think a good culture, 328 00:16:05,920 --> 00:16:09,840 especially the people around you who support refactoring as well, 329 00:16:09,840 --> 00:16:11,120 I think that makes a big difference. 330 00:16:11,120 --> 00:16:13,960 And probably I would as well. A coach that probably can help 331 00:16:13,960 --> 00:16:16,920 you point out like which parts that should be refactored. 332 00:16:16,920 --> 00:16:20,600 I think that also helps as well. And also why doing this at the 333 00:16:20,600 --> 00:16:22,160 beginning makes more sense, right? 334 00:16:22,160 --> 00:16:24,560 Because I can understand if a developer blocks a merger 335 00:16:24,560 --> 00:16:27,880 request that does a refactoring five years later where the code 336 00:16:27,880 --> 00:16:32,000 is way more sensitive, etcetera. It is much harder to block such 337 00:16:32,000 --> 00:16:34,800 merger requests if it's at the beginning when the code is still 338 00:16:34,800 --> 00:16:37,040 fresh. You know, just out of the oven 339 00:16:37,440 --> 00:16:39,440 if you will. So that's why it needs to be 340 00:16:39,440 --> 00:16:40,920 constant. Yeah. 341 00:16:41,400 --> 00:16:45,800 So let's move on to your six principles of how we can make a 342 00:16:45,800 --> 00:16:47,600 simple object oriented design, right. 343 00:16:47,600 --> 00:16:49,680 So I think the keyword here is simple. 344 00:16:49,680 --> 00:16:51,960 You mentioned it a couple of times as well, simple. 345 00:16:52,160 --> 00:16:54,560 Sometimes it's not intuitive as well. 346 00:16:54,560 --> 00:16:57,200 That is simple, right? So maybe if you can walk us 347 00:16:57,280 --> 00:17:01,200 through the six characteristics or six principles that you 348 00:17:01,280 --> 00:17:04,000 outline in the book at the high level, and afterwards maybe we 349 00:17:04,000 --> 00:17:07,359 can go slightly deeper, 11 each in the next conversation. 350 00:17:07,359 --> 00:17:09,760 Yeah. For sure the first one in the 351 00:17:09,760 --> 00:17:14,200 book is making code small and the intuition there is that code 352 00:17:14,200 --> 00:17:16,079 that is small. So think of lines of code. 353 00:17:16,280 --> 00:17:19,359 Even a code that has less lines of code is much easier to 354 00:17:19,359 --> 00:17:21,880 maintain that a method that is super large. 355 00:17:22,400 --> 00:17:23,720 Right? So one of the arguments I made 356 00:17:23,720 --> 00:17:26,880 there is that you have to make sure that your units are always 357 00:17:26,880 --> 00:17:28,480 small. It's better to have multiple 358 00:17:28,480 --> 00:17:30,280 small units than one super large unit. 359 00:17:30,880 --> 00:17:34,160 Then I also talk about keeping objects consistent. 360 00:17:34,600 --> 00:17:37,240 So if you're in an object oriented system, your objects 361 00:17:37,240 --> 00:17:42,360 hold data and those objects commonly relate to other objects 362 00:17:42,720 --> 00:17:45,320 and they together represent some sort of very complex business 363 00:17:45,320 --> 00:17:47,080 functionality. And it's very common that you 364 00:17:47,080 --> 00:17:50,600 change something inside of the object and you have to propagate 365 00:17:50,600 --> 00:17:52,560 this change and make everything consistent, right? 366 00:17:52,560 --> 00:17:54,640 So if you have, I don't know, a shopping cart and a list of 367 00:17:54,680 --> 00:17:57,520 products and items, if you add a new item, you need to make sure 368 00:17:57,520 --> 00:18:01,040 that the cards has the new total price to pay, for example. 369 00:18:01,040 --> 00:18:02,800 This is what I mean by consistency. 370 00:18:03,160 --> 00:18:06,600 And if you don't pay attention, it's very easy for you to end up 371 00:18:06,600 --> 00:18:08,480 in a design where things are inconsistent. 372 00:18:08,480 --> 00:18:12,920 So maybe the list of items in your cards, if you sum all the 373 00:18:12,920 --> 00:18:15,880 prices of them, the sum is different from the total value 374 00:18:15,880 --> 00:18:17,760 you have in your shopping cart object. 375 00:18:18,160 --> 00:18:21,000 And this is of course very problematic, leads to bugs. 376 00:18:21,200 --> 00:18:23,200 So you got to make sure that they are consistent at all 377 00:18:23,200 --> 00:18:25,600 times. Then I talk about managing 378 00:18:25,600 --> 00:18:28,240 dependencies. So in object oriented systems 379 00:18:28,240 --> 00:18:31,840 you depend on things from, for example, one class depend on 380 00:18:31,840 --> 00:18:34,400 another class, or a module depends on another module. 381 00:18:34,880 --> 00:18:37,920 And then there I discuss a few rules on how we can manage those 382 00:18:37,920 --> 00:18:39,840 dependencies. Because you cannot avoid 383 00:18:39,840 --> 00:18:43,520 dependencies, you have to depend on smaller classes to make the 384 00:18:43,520 --> 00:18:46,280 whole behaviour work. But how do you make sure that 385 00:18:46,280 --> 00:18:48,880 those dependencies don't hurt you so much? 386 00:18:49,480 --> 00:18:52,760 I didn't talk about abstractions and how to design grid 387 00:18:52,760 --> 00:18:56,120 abstractions and to meet this chapter is key because this is 388 00:18:56,120 --> 00:18:57,920 key in object oriented programming. 389 00:18:58,360 --> 00:19:02,440 Making sure that in in parts of the system that we need a lot of 390 00:19:02,440 --> 00:19:05,240 flexibility, making sure that you have a good abstraction 391 00:19:05,240 --> 00:19:10,440 there so it's easy to keep adding more business rules or 392 00:19:10,640 --> 00:19:14,440 making sure that you can easily change something that happens in 393 00:19:14,440 --> 00:19:17,320 a very complex slope is very important, right? 394 00:19:17,320 --> 00:19:19,480 So the example is you don't want to, you know, if you're doing 395 00:19:19,480 --> 00:19:23,640 this very complex system that has to calculate taxes for 100 396 00:19:23,640 --> 00:19:26,160 different countries, you don't want to have 100 if statements 397 00:19:26,160 --> 00:19:29,120 in one single B class. And you want it to be easy to 398 00:19:29,120 --> 00:19:32,000 add country #101 because apparently that's part of your 399 00:19:32,000 --> 00:19:35,320 business, right? So this type of stuff is very 400 00:19:35,320 --> 00:19:37,160 important. If you're looking for simple 401 00:19:37,160 --> 00:19:40,880 objectory and design, then I talk a lot about how to handle 402 00:19:40,880 --> 00:19:43,520 external dependencies and infrastructure. 403 00:19:44,000 --> 00:19:47,320 And what I mean by that is when you're designing your object 404 00:19:47,320 --> 00:19:50,400 oriented system, you're thinking of classes and how they relate 405 00:19:50,400 --> 00:19:53,200 to each other and how they keep consistency among each other and 406 00:19:53,200 --> 00:19:55,960 blah, blah, blah. And this is all beautiful and 407 00:19:55,960 --> 00:19:59,200 isolated, right? This lives in this design world, 408 00:19:59,560 --> 00:20:01,920 if you will. But at some point, your system 409 00:20:01,920 --> 00:20:04,680 will have to talk to some external system, let's say a 410 00:20:04,680 --> 00:20:06,720 database, right? You have to persist stuff into 411 00:20:06,720 --> 00:20:09,720 the database, or you have to make a web service call to an 412 00:20:09,720 --> 00:20:13,000 external party, or you have to use a library that you didn't 413 00:20:13,000 --> 00:20:16,160 write yourself. So it is very common that in the 414 00:20:16,160 --> 00:20:19,160 systems you have to integrate with things you don't really own 415 00:20:19,160 --> 00:20:21,440 and control. And if you don't pay attention, 416 00:20:21,440 --> 00:20:24,640 it's very easy to, you know, get super coupled to this external 417 00:20:24,640 --> 00:20:28,240 infrastructure or suddenly your code is hard to test because you 418 00:20:28,240 --> 00:20:31,240 depend on this third party, so on and so forth. 419 00:20:31,760 --> 00:20:33,840 And finally, I talk about modularization. 420 00:20:34,240 --> 00:20:38,000 That is, in very large software systems, you sort of have 421 00:20:38,120 --> 00:20:41,320 multiple domains within one design. 422 00:20:41,320 --> 00:20:44,280 And then of course, you don't want to have this in one big 423 00:20:44,760 --> 00:20:46,760 messy bucket. You want to have different 424 00:20:46,760 --> 00:20:49,200 modules and those modules talk to each other. 425 00:20:49,640 --> 00:20:52,920 So this is almost like seeing, you know, the coupling between 426 00:20:52,920 --> 00:20:55,400 classes that I spoke at the beginning of the book, but now 427 00:20:55,400 --> 00:20:58,000 we're talking about modules, modules talking to other 428 00:20:58,000 --> 00:21:00,240 modules. This chapter makes a lot of 429 00:21:00,240 --> 00:21:03,840 sense if you're really working on a very large software system. 430 00:21:04,440 --> 00:21:06,840 So those are the six principles that I cover in the book. 431 00:21:07,800 --> 00:21:09,320 Yeah. So I think indeed those are the 432 00:21:09,320 --> 00:21:11,920 six principles, 6 characteristics that you think 433 00:21:11,920 --> 00:21:15,560 will lead us to a simple and better object oriented design, 434 00:21:15,560 --> 00:21:17,720 right. So I think let's probably try to 435 00:21:17,720 --> 00:21:19,800 cover each of them in a more details. 436 00:21:20,000 --> 00:21:23,320 So the first one is something about making code small. 437 00:21:23,560 --> 00:21:26,440 So you mentioned about, you know, maybe lines of code, maybe 438 00:21:26,440 --> 00:21:30,320 smaller classes of functions. So is that the only thing that 439 00:21:30,320 --> 00:21:33,880 we should care about in terms of making code small or are there 440 00:21:33,880 --> 00:21:36,520 any other practices that we should think about in terms of 441 00:21:36,520 --> 00:21:39,520 trying to make our code small? Yeah. 442 00:21:39,560 --> 00:21:42,640 So for me, rule of thumb number one there and the most important 443 00:21:42,640 --> 00:21:45,640 one is try to keep your units very small. 444 00:21:46,000 --> 00:21:49,400 And by units I mean your methods, try to keep them small 445 00:21:49,400 --> 00:21:51,600 and your classes, try to keep your classes small. 446 00:21:51,880 --> 00:21:55,280 And if they start to grow, and they will start to grow at some 447 00:21:55,280 --> 00:21:59,280 point, refractory #1 is how can I move some code around so that 448 00:21:59,280 --> 00:22:02,320 it leaves this big class and then it goes to another class or 449 00:22:02,320 --> 00:22:04,880 to another method, right? Maybe your public method starts 450 00:22:04,880 --> 00:22:06,720 to grow and then you do that distracting method of 451 00:22:06,720 --> 00:22:10,040 refactoring that everyone sort of knows your ID does for you, 452 00:22:10,360 --> 00:22:13,520 you move to a different method. So that's sort of the gist of 453 00:22:13,520 --> 00:22:15,120 what I discussed in that chapter. 454 00:22:15,200 --> 00:22:19,640 And my point there being that if you're in a small units, you are 455 00:22:19,640 --> 00:22:21,880 going to understand it much, much, much faster. 456 00:22:22,240 --> 00:22:25,600 And when you move a piece of code to another class, you're 457 00:22:25,600 --> 00:22:27,800 basically saying, I, I don't have to read this piece of code 458 00:22:27,800 --> 00:22:30,400 when I'm reading this unit that I'm focusing on right now. 459 00:22:30,920 --> 00:22:34,080 And if you give, let's say you extract a bunch of likes to a 460 00:22:34,080 --> 00:22:35,920 new class, you're going to give this Class A name. 461 00:22:35,920 --> 00:22:37,800 You're going to give the method a beautiful name. 462 00:22:38,160 --> 00:22:40,760 So when I'm reading the original class and I see a method call to 463 00:22:40,760 --> 00:22:44,200 there, that method call explains to me what is going on. 464 00:22:44,200 --> 00:22:47,160 I don't have to read the implementation details of that. 465 00:22:47,520 --> 00:22:50,560 So I feel like once you're forced to only work in small 466 00:22:50,560 --> 00:22:56,040 units, you're forced to write code that explains intents first 467 00:22:56,160 --> 00:23:00,000 and then implementation later. And finding ways not to read 468 00:23:00,000 --> 00:23:02,240 implementation is what makes you more productive. 469 00:23:02,240 --> 00:23:04,320 You don't want to read every detail, right? 470 00:23:04,320 --> 00:23:06,400 Once you're, you know, maintaining something, you just 471 00:23:06,400 --> 00:23:10,040 care first of all the intents and then you go crazy and debug 472 00:23:10,320 --> 00:23:12,920 whatever is going on. So that's sort of my arguments 473 00:23:12,920 --> 00:23:15,960 number one in the book that I think it's not so hard to follow 474 00:23:16,200 --> 00:23:18,120 and I think it does make a lot of difference. 475 00:23:18,880 --> 00:23:20,840 Yeah. So I think intuitively it's not 476 00:23:20,840 --> 00:23:23,680 so hard to follow, but I think, again, in practice, it seems 477 00:23:23,680 --> 00:23:26,960 very hard to have the discipline to actually continue doing this, 478 00:23:26,960 --> 00:23:28,680 right? So one of the arguments, 479 00:23:28,680 --> 00:23:30,960 probably some people might have these arguments. 480 00:23:31,360 --> 00:23:35,400 So jumping into multiple methods or classes breaks the flow. 481 00:23:35,560 --> 00:23:38,160 You have to open multiple tabs and, you know, navigate through 482 00:23:38,160 --> 00:23:40,600 different files. And the second thing is about 483 00:23:40,600 --> 00:23:43,160 finding good names. Yeah, of course we have to be 484 00:23:43,160 --> 00:23:46,440 able to explain the intent, but sometimes finding a name or 485 00:23:46,440 --> 00:23:49,600 function name or method name or class name is not so easy. 486 00:23:49,800 --> 00:23:52,160 So maybe if you have tips for these two things. 487 00:23:52,800 --> 00:23:54,800 For sure. And your first argument is a 488 00:23:54,800 --> 00:23:57,960 common argument that usually people that defend having 489 00:23:57,960 --> 00:24:00,680 everything in one place usually raise right. 490 00:24:00,680 --> 00:24:02,720 That is, I don't want to navigate through different 491 00:24:02,720 --> 00:24:04,360 classes and methods and etcetera. 492 00:24:04,720 --> 00:24:06,480 And the point is, if you're really designing with 493 00:24:06,480 --> 00:24:10,480 abstraction in mind, you won't have to jump into those other 494 00:24:10,480 --> 00:24:12,680 classes as much as you think you would. 495 00:24:13,080 --> 00:24:15,760 Because usually you know, what you're doing is you read the 496 00:24:15,760 --> 00:24:19,240 intent and then you find out this is the specific part they 497 00:24:19,240 --> 00:24:21,840 need to really dive into. And then you just dive into that 498 00:24:21,840 --> 00:24:24,640 specific part. If your design is forcing you to 499 00:24:24,640 --> 00:24:27,360 read 1000 lines of code every time you have to do some 500 00:24:27,360 --> 00:24:30,320 maintenance in that piece of code, the abstraction is wrong. 501 00:24:30,720 --> 00:24:33,200 So I think that's usually my response to that. 502 00:24:33,600 --> 00:24:36,160 Navigating isn't so much of a problem today anymore, right? 503 00:24:36,160 --> 00:24:38,880 IDs are also very good. So even if sometimes you have to 504 00:24:38,880 --> 00:24:42,040 do some navigation, just learn how to use your ID and that's 505 00:24:42,040 --> 00:24:44,560 will make you way more productive for sure. 506 00:24:45,000 --> 00:24:47,480 And then the other comment from you was the naming. 507 00:24:47,800 --> 00:24:49,760 Yes, indeed, naming is very tricky. 508 00:24:50,080 --> 00:24:54,120 I don't even attempt to give a lot of tips on how to name 509 00:24:54,120 --> 00:24:57,920 because I should like the the best one is keep trying, keep 510 00:24:57,920 --> 00:24:59,800 refactoring. As soon as you learn more about 511 00:24:59,800 --> 00:25:01,000 the domain. I think that's actually the 512 00:25:01,000 --> 00:25:03,760 rule, like the suggestion I give and they will, you know, just 513 00:25:03,760 --> 00:25:05,000 keep trying. Just keep refactoring. 514 00:25:05,000 --> 00:25:07,200 The more you learn about the domain, the more you you rename 515 00:25:07,200 --> 00:25:09,480 it. But once you get to a reasonable 516 00:25:09,480 --> 00:25:12,240 good name, it doesn't have to be a perfect name, but a reasonably 517 00:25:12,240 --> 00:25:14,920 good name, then life's so much better, right? 518 00:25:14,920 --> 00:25:16,840 Because again, you just read the method call and they don't know 519 00:25:16,840 --> 00:25:18,360 what it does without going to that method. 520 00:25:19,000 --> 00:25:21,560 And also maybe maybe a comment just said it's, it's very hard. 521 00:25:21,560 --> 00:25:23,800 It is because you know, life is hard. 522 00:25:23,800 --> 00:25:26,040 And then sometimes you're like, where do I break this code, 523 00:25:26,360 --> 00:25:27,800 right? Maybe you don't find natural 524 00:25:27,800 --> 00:25:31,440 spots for you to extract something to another method or 525 00:25:31,440 --> 00:25:33,480 to another class In my book, I'll give an example, right? 526 00:25:33,480 --> 00:25:36,040 Sometimes you try to extract something to a private method, 527 00:25:36,040 --> 00:25:37,720 but then you have to take together, you know, you create a 528 00:25:37,720 --> 00:25:40,840 function with 10 parameters, you know, like, yeah, do I want to 529 00:25:40,840 --> 00:25:43,600 function with 10 parameters? You know, that it's very real to 530 00:25:43,600 --> 00:25:46,640 me and blah, blah, blah. So that is the hard part in real 531 00:25:46,640 --> 00:25:49,920 life is because sometimes there's no natural cutting point 532 00:25:49,920 --> 00:25:52,960 for you to extract something, but you have to, you know, keep 533 00:25:52,960 --> 00:25:55,120 working until it emerges and you find them. 534 00:25:56,040 --> 00:25:57,880 Yeah, So I think thanks for the tips, right? 535 00:25:57,880 --> 00:26:01,280 So for those of you who still find it difficult to extract the 536 00:26:01,280 --> 00:26:03,720 units to become smaller and smaller, please do give it a 537 00:26:03,720 --> 00:26:06,080 try. I see some developers also try 538 00:26:06,080 --> 00:26:09,600 to create sections within the big function by putting in 539 00:26:09,600 --> 00:26:12,000 comments. So it's like giving names to a 540 00:26:12,000 --> 00:26:14,560 certain sections, right? But it's still one big line. 541 00:26:14,560 --> 00:26:17,160 So instead of doing that, maybe extract as a private method and 542 00:26:17,160 --> 00:26:20,040 give it a proper name that expressed the intent. 543 00:26:20,320 --> 00:26:22,520 So I think those are really, really great tips, right? 544 00:26:22,520 --> 00:26:24,960 So please try to make your units smaller. 545 00:26:25,240 --> 00:26:28,400 So let's move on to the next principle which I find this is 546 00:26:28,400 --> 00:26:31,080 also tricky sometimes. In object oriented, you 547 00:26:31,080 --> 00:26:33,160 mentioned about keeping objects consistent. 548 00:26:33,520 --> 00:26:36,960 I think in some theory they call it invariance as well, right? 549 00:26:36,960 --> 00:26:39,560 So when you create objects, right, it should maintain the 550 00:26:39,560 --> 00:26:43,680 invariance within that objects. So tell us more about this 551 00:26:43,680 --> 00:26:45,640 inconsistency, right? Why it is a problem? 552 00:26:45,640 --> 00:26:47,200 Why? It tends to create a lot of 553 00:26:47,200 --> 00:26:49,680 bugs. Yes, sure. 554 00:26:49,920 --> 00:26:52,840 So by consistency, I mean whenever you have an object, you 555 00:26:52,840 --> 00:26:55,080 have to trust on the state of that object, right? 556 00:26:55,080 --> 00:26:57,400 So if you have a shopping cart in your hands, you should call 557 00:26:57,400 --> 00:27:00,480 the method. Get me the total amount of these 558 00:27:00,480 --> 00:27:02,840 cards. Give me how many products are 559 00:27:02,840 --> 00:27:04,520 there? You have to trust the answer. 560 00:27:04,880 --> 00:27:08,760 The answer should be correct. You shouldn't have to do a lot 561 00:27:08,760 --> 00:27:11,520 of work yourself to make sure that the object is in the 562 00:27:11,520 --> 00:27:13,000 correct state. It needs to be. 563 00:27:13,000 --> 00:27:14,920 The object needs to do it by itself. 564 00:27:15,680 --> 00:27:19,040 But it's easier said than done, of course, because as soon as 565 00:27:19,040 --> 00:27:21,800 objects start to grow and then they start to depend on other 566 00:27:21,800 --> 00:27:25,120 things, and then suddenly you have this very complex 567 00:27:25,200 --> 00:27:28,080 aggregation of objects representing some very complex 568 00:27:28,360 --> 00:27:31,360 business rule or whatever. Then it gets really tricky 569 00:27:31,360 --> 00:27:34,200 because you know, maybe one object super down the line 570 00:27:34,200 --> 00:27:37,040 changes something and this change needs to be propagated 571 00:27:37,440 --> 00:27:39,120 upstream and downstream, whatever. 572 00:27:39,680 --> 00:27:42,520 And I think that's what you need to make sure this is when the 573 00:27:42,520 --> 00:27:45,280 program starts to happen, right? In this very complex entities, 574 00:27:45,640 --> 00:27:48,640 at least in my experience and in the book, I tried to make a 575 00:27:48,640 --> 00:27:51,720 discussion because to me, the discussion on this is where to 576 00:27:51,720 --> 00:27:54,400 ensure the consistency. Who should ensure the 577 00:27:54,400 --> 00:27:55,960 consistency? Should it be? 578 00:27:55,960 --> 00:27:57,760 So for example, the first argument that I make, it should 579 00:27:57,760 --> 00:27:59,880 never be the client, right? So the client of the class 580 00:27:59,880 --> 00:28:02,280 should never be the one sharing consistency should be somewhere 581 00:28:02,280 --> 00:28:04,440 else. But then in the book, I go into 582 00:28:04,440 --> 00:28:07,000 the details because sometimes, you know, to ensure consistency, 583 00:28:07,240 --> 00:28:10,200 you also need to make a database call because maybe you need some 584 00:28:10,200 --> 00:28:12,880 data from the database. And then usually we don't like 585 00:28:12,880 --> 00:28:15,520 to make database calls from entities, right? 586 00:28:15,520 --> 00:28:17,640 Because you don't like to couple entities with databases. 587 00:28:17,640 --> 00:28:20,720 So then this means I cannot really do the consistency check 588 00:28:20,720 --> 00:28:23,600 inside of my entity. So this starts to accumulate. 589 00:28:24,120 --> 00:28:26,160 And then in in the book I give some rules of thumb. 590 00:28:26,160 --> 00:28:28,760 For example, from the 1st place you should try is the entity 591 00:28:28,760 --> 00:28:30,400 itself. Maybe inside of the class. 592 00:28:30,600 --> 00:28:34,120 If all the information is there, just do it there so you don't 593 00:28:34,120 --> 00:28:37,360 need to go somewhere else. But then I need a database call 594 00:28:37,360 --> 00:28:39,560 or whatever. Then maybe I have to introduce 595 00:28:39,560 --> 00:28:42,760 something in between that ensures that that object is 596 00:28:42,760 --> 00:28:46,160 always in a consistent state. This is less ideal, of course, 597 00:28:46,160 --> 00:28:48,920 because then, you know, you have to make sure that clients don't, 598 00:28:49,160 --> 00:28:51,960 you know, they make the call to the entity without going through 599 00:28:52,000 --> 00:28:53,560 this small day you had to create. 600 00:28:53,560 --> 00:28:56,400 So you have to play a little bit with your design to make sure 601 00:28:56,440 --> 00:28:59,040 that this happens or this doesn't happen, that that 602 00:28:59,040 --> 00:29:02,480 probably doesn't happen. But this is a trick and maybe I 603 00:29:02,480 --> 00:29:05,160 went to technical right away, but then if I zoom back a little 604 00:29:05,160 --> 00:29:07,720 bit, I think the the point is you got to ensure your objects 605 00:29:07,800 --> 00:29:10,240 are consistent and you have to find a place to make it 606 00:29:10,240 --> 00:29:12,840 consistent and you have to make it simple for the clients. 607 00:29:12,840 --> 00:29:15,160 It should not be the responsibility of the clients to 608 00:29:15,160 --> 00:29:16,880 ensure that the object is consistent. 609 00:29:17,440 --> 00:29:19,920 I think that's indeed a very important point, right? 610 00:29:19,920 --> 00:29:22,760 You have to ensure that the client does not understand how 611 00:29:22,760 --> 00:29:25,160 to assemble your consistent object, right? 612 00:29:25,160 --> 00:29:27,680 So to speak, right? So I think sometimes this tends 613 00:29:27,680 --> 00:29:30,800 to happen if let's say you are a single person trying to work on 614 00:29:30,800 --> 00:29:33,840 those multiple classes, right? Because maybe the understanding 615 00:29:33,840 --> 00:29:37,560 leaks all over the places. So you unconsciously create that 616 00:29:37,560 --> 00:29:40,520 behaviour simply because you were not so conscious about the 617 00:29:40,520 --> 00:29:42,600 design, right? And I think sometimes also 618 00:29:42,600 --> 00:29:45,880 frameworks kind of like lead us to that thing, right? 619 00:29:45,880 --> 00:29:48,680 So for example, in some frameworks you have the getter 620 00:29:48,680 --> 00:29:53,000 setters that are exposed as if like you can call that publicly. 621 00:29:53,320 --> 00:29:56,080 So I think I can see some legacy code last time right here, you 622 00:29:56,080 --> 00:29:58,920 create a new object, right? And then you have set one, set 623 00:29:58,920 --> 00:30:01,680 two, set three, set four. I think that's also like a best 624 00:30:01,680 --> 00:30:04,280 practice. And I think you mentioned a few 625 00:30:04,280 --> 00:30:06,360 times about entity and maybe aggregates, right? 626 00:30:06,360 --> 00:30:10,240 So I think using domain driven design as the concept to 627 00:30:10,240 --> 00:30:13,000 maintain a good design is something that is very, very 628 00:30:13,400 --> 00:30:17,480 useful for us to implement. So if let's say those people who 629 00:30:17,480 --> 00:30:20,320 are stuck with their framework, what can you suggest in order 630 00:30:20,320 --> 00:30:21,880 for them to be conscious about it? 631 00:30:21,880 --> 00:30:24,560 That's the first thing. And also try to adopt A better 632 00:30:24,560 --> 00:30:26,640 design. Yeah, good question. 633 00:30:26,640 --> 00:30:28,800 Because frameworks are opinionated, right? 634 00:30:28,800 --> 00:30:30,360 And they do this because they want to give you more 635 00:30:30,360 --> 00:30:32,360 productivity. If you just follow their rules, 636 00:30:32,440 --> 00:30:35,640 things are much better for you. And the suggestion I make in my 637 00:30:35,640 --> 00:30:37,320 book is don't fight your framework. 638 00:30:37,720 --> 00:30:40,880 As soon as you pick your framework, accept its decisions 639 00:30:41,040 --> 00:30:44,840 and see what you can do so that they don't really harm you that 640 00:30:44,840 --> 00:30:47,080 much. I feel like modern frameworks, 641 00:30:47,080 --> 00:30:50,240 all the days, they are quite less opinionated as they were in 642 00:30:50,240 --> 00:30:51,840 the past. So that makes your life a little 643 00:30:51,840 --> 00:30:53,880 bit easier. You have more freedom in design. 644 00:30:54,200 --> 00:30:56,240 But some frameworks from the past, indeed they were quite 645 00:30:56,240 --> 00:30:58,600 opinionated. I remember suffering a lot with 646 00:30:58,600 --> 00:31:01,560 JSS, you know, and this type of technologies from the days. 647 00:31:01,920 --> 00:31:04,560 So don't write your framework. And why do I say this explicitly 648 00:31:04,560 --> 00:31:07,200 in the book? Because I see sometimes advice 649 00:31:07,200 --> 00:31:10,080 on how you can, you know, abstract your whole domain model 650 00:31:10,080 --> 00:31:13,120 away from your framework or for whatever other decisions you 651 00:31:13,120 --> 00:31:14,680 take. So, you know, it really lives in 652 00:31:14,680 --> 00:31:17,120 a bubble. I feel like great, you know, 653 00:31:17,120 --> 00:31:19,800 maybe for some very specific cases, you really want to 654 00:31:19,800 --> 00:31:21,840 abstract everything away from your domain. 655 00:31:22,280 --> 00:31:26,440 But in most software systems that I've seen, it is OK to be 656 00:31:26,440 --> 00:31:28,320 coupled to the framework. You're not going to move from 657 00:31:28,320 --> 00:31:32,560 frameworks every month or so. So I think it's also about 658 00:31:32,560 --> 00:31:35,560 finding the right balance between I want to be productive 659 00:31:35,680 --> 00:31:38,720 and I want to have a perfect design, you know? 660 00:31:39,440 --> 00:31:41,960 Yeah, so indeed, right. Sometimes framework gives you a 661 00:31:41,960 --> 00:31:45,840 boost of productivity, but also do understand the best practice, 662 00:31:45,840 --> 00:31:49,480 right, in terms of design and what we should avoid in terms of 663 00:31:49,480 --> 00:31:52,560 how to make, for example, the classes, function calls and 664 00:31:52,560 --> 00:31:54,040 things like that. So be aware of that. 665 00:31:54,240 --> 00:31:56,720 And I think one thing very important to make sure object is 666 00:31:56,720 --> 00:31:58,320 consistent about validation, right? 667 00:31:58,360 --> 00:32:01,240 So having the precondition or maybe some kind of validation 668 00:32:01,240 --> 00:32:04,720 roles before you create a object or execute something is very, 669 00:32:04,720 --> 00:32:07,000 very important. Maybe let's move on to the next 670 00:32:07,000 --> 00:32:08,840 one, which is about managing dependencies. 671 00:32:09,200 --> 00:32:12,040 I think the very, very first advice you give is minimize 672 00:32:12,040 --> 00:32:13,680 dependencies. The less the better. 673 00:32:14,000 --> 00:32:16,160 So how can we minimize dependencies? 674 00:32:16,880 --> 00:32:19,600 Yeah. So why do I think this is a good 675 00:32:19,600 --> 00:32:21,440 advice? Because if you have a class that 676 00:32:21,440 --> 00:32:25,000 depends on other twenty classes, everything becomes more complex, 677 00:32:25,000 --> 00:32:26,160 right? The the code is just more 678 00:32:26,160 --> 00:32:28,920 complex because it probably makes calls to those 20 679 00:32:29,040 --> 00:32:31,800 dependencies. Those dependencies do stuff, 680 00:32:31,800 --> 00:32:34,440 they change state in the system, and then you have to handle all 681 00:32:34,440 --> 00:32:36,440 these things. So this just increases 682 00:32:36,440 --> 00:32:38,560 complexity. And of course the natural 683 00:32:38,560 --> 00:32:42,840 problem of coupling that is if one dependency changes and it 684 00:32:42,840 --> 00:32:45,640 depend on that, maybe if it's a breaking change, that will also 685 00:32:45,680 --> 00:32:49,120 impact you. So I think the less dependencies 686 00:32:49,120 --> 00:32:53,440 the better as a general rule. But you of course, you have to 687 00:32:53,440 --> 00:32:57,080 always depend on stuff. And then the whole point of the 688 00:32:57,080 --> 00:32:59,640 exercise is how to find this balance. 689 00:32:59,640 --> 00:33:01,800 And for example, it's maybe instead of depending on 10 690 00:33:01,800 --> 00:33:05,200 classes, maybe you can group some of those dependencies. 691 00:33:05,640 --> 00:33:08,080 So you get three of those dependencies and then you group 692 00:33:08,080 --> 00:33:10,920 them into another class. You give a beautiful domain 693 00:33:11,160 --> 00:33:13,480 related name to this class that groups these three other 694 00:33:13,480 --> 00:33:15,440 dependencies. And the original class now only 695 00:33:15,440 --> 00:33:17,920 depends on one set of depending on the other three. 696 00:33:18,360 --> 00:33:21,480 So very more often than not, when you look at those classes, 697 00:33:21,480 --> 00:33:25,240 you can find groups, things that you can group and give a new 698 00:33:25,240 --> 00:33:28,960 domain term for this operation and move this to another place. 699 00:33:29,360 --> 00:33:31,520 So this is usually refactoring number one that I feel quite 700 00:33:31,520 --> 00:33:34,080 feasible for a lot of the business systems out there. 701 00:33:34,760 --> 00:33:36,760 Yeah. So I think that's a very, very 702 00:33:36,760 --> 00:33:39,760 useful tips, right? So if you start seeing a lot of 703 00:33:39,800 --> 00:33:42,200 maybe imports, right? So in a lot of programming 704 00:33:42,200 --> 00:33:44,520 language, you can sense dependencies by looking at the 705 00:33:44,520 --> 00:33:47,400 import statements, right? If you do see a lot of classes 706 00:33:47,400 --> 00:33:49,360 that you imported or dependencies you import, so 707 00:33:49,360 --> 00:33:52,160 maybe that's the first sign, right, that you maybe should try 708 00:33:52,160 --> 00:33:54,520 breaking them up into multiple units, right? 709 00:33:55,000 --> 00:33:58,440 And I think another useful tips that I find in your book is you 710 00:33:58,440 --> 00:34:00,760 mentioned separate high level and low level code, right? 711 00:34:01,120 --> 00:34:02,720 So separating the what and the how. 712 00:34:03,040 --> 00:34:06,480 So tell us about this principle and how we can implement this. 713 00:34:07,240 --> 00:34:09,880 Sure. So I mentioned before in this 714 00:34:09,880 --> 00:34:12,520 interview, right, that I think to me, nice code is the one that 715 00:34:12,560 --> 00:34:15,280 you, when you really read the intent and not implementation 716 00:34:15,280 --> 00:34:19,239 detail. And this becomes very important 717 00:34:19,239 --> 00:34:23,120 was you're in a very complex business rule that is not only 718 00:34:23,120 --> 00:34:25,600 complex from an intent point of view, but also from an 719 00:34:25,600 --> 00:34:28,840 implementation point of view. And there what you want is you 720 00:34:28,840 --> 00:34:31,080 want to open the first class that implements the business 721 00:34:31,080 --> 00:34:35,000 rule and you want to read like a 10/15/20 lines that look like an 722 00:34:35,000 --> 00:34:37,639 algorithm. It only expresses what happens, 723 00:34:37,639 --> 00:34:40,440 not how it happens. And this is to me, the 724 00:34:40,440 --> 00:34:43,639 separation between high level and and low level, right? 725 00:34:43,719 --> 00:34:45,600 And you don't want this for your whole system, right? 726 00:34:45,639 --> 00:34:47,360 Because you don't need this for the whole system. 727 00:34:47,719 --> 00:34:50,719 But for the complex parts, what you want to do is to have this 728 00:34:51,000 --> 00:34:55,480 entry point that is purely intense and then you let low 729 00:34:55,480 --> 00:34:58,920 level classes implement the intent and do the job and do the 730 00:34:58,920 --> 00:35:01,600 hard work, right? So this is the separation that I 731 00:35:01,600 --> 00:35:04,240 discuss a lot in my book. And I think it's very important 732 00:35:04,640 --> 00:35:07,360 because it does help you to manage dependencies, right? 733 00:35:07,360 --> 00:35:09,120 When your dependencies focus on intent. 734 00:35:09,120 --> 00:35:12,360 So it's more high level. Think of an interface, right? 735 00:35:12,360 --> 00:35:14,040 Imagine you have some business rule and you have 10 736 00:35:14,040 --> 00:35:15,480 implementation of this business rule. 737 00:35:15,480 --> 00:35:17,320 So you give it a common interface. 738 00:35:17,720 --> 00:35:21,680 This interface expresses intent. It's it's high level and it's 739 00:35:21,680 --> 00:35:24,120 very stable. So if you're depending on such 740 00:35:24,120 --> 00:35:26,440 an interface, you have a dependency there. 741 00:35:26,440 --> 00:35:30,040 But this dependency doesn't hurt you so much because interfaces 742 00:35:30,040 --> 00:35:32,080 like these tend to be very stable. 743 00:35:32,520 --> 00:35:35,840 So what you have is for this part of the code base, you want 744 00:35:35,840 --> 00:35:39,280 to have code that expresses intent and only depend on high 745 00:35:39,280 --> 00:35:41,960 level things like interfaces and abstract classes. 746 00:35:42,160 --> 00:35:43,600 And this tends to be quite stable. 747 00:35:43,600 --> 00:35:46,640 And then lots of flow level classes that implement those 748 00:35:46,640 --> 00:35:50,240 interfaces and get the job done. So this is funny because this 749 00:35:50,240 --> 00:35:52,480 section of this book, I was always in doubt, should it fit 750 00:35:52,480 --> 00:35:55,360 this into managing dependencies or design good abstractions? 751 00:35:55,360 --> 00:35:58,200 And in the original, one of the first drafts of the book, this 752 00:35:58,200 --> 00:36:00,760 was one chapter, but it became too big that I decided to break. 753 00:36:01,160 --> 00:36:03,920 But those two chapters, this one and the one we're going to 754 00:36:03,920 --> 00:36:06,240 discuss next, they have a huge intersection. 755 00:36:06,960 --> 00:36:08,920 So I think that's a very useful tips. 756 00:36:08,920 --> 00:36:11,760 Again, from my understanding, maybe if I summarize it, so you 757 00:36:11,760 --> 00:36:14,040 separate the high level intent from the low level 758 00:36:14,040 --> 00:36:17,120 implementation, right? So if the client always refers 759 00:36:17,120 --> 00:36:19,640 to the high level intent, they don't actually need to see all 760 00:36:19,640 --> 00:36:22,600 this low level dependencies. And hence you actually manage 761 00:36:22,600 --> 00:36:26,080 dependencies by minimizing those classes that they need to import 762 00:36:26,080 --> 00:36:27,640 or they need to understand, right? 763 00:36:27,960 --> 00:36:30,720 So I think that's a very useful tip for a better design. 764 00:36:31,040 --> 00:36:33,280 The next one you mentioned about good abstractions, right? 765 00:36:33,280 --> 00:36:35,000 I think this is sometimes tricky. 766 00:36:35,000 --> 00:36:38,080 So finding good abstractions is always difficult unless you kind 767 00:36:38,080 --> 00:36:40,640 of like have a well defined business rules that stays the 768 00:36:40,640 --> 00:36:42,480 same. But if it's like a novel 769 00:36:42,480 --> 00:36:45,200 software, I think it's really, really difficult to find good 770 00:36:45,200 --> 00:36:47,360 abstractions. How can we find a better 771 00:36:47,360 --> 00:36:50,640 abstractions, Mauricio? Yeah, that's the $1 million 772 00:36:50,640 --> 00:36:52,600 question. I think finding the perfect 773 00:36:52,600 --> 00:36:56,440 abstraction as I've been, you know, restating here is 774 00:36:56,440 --> 00:36:57,760 impossible. What you want to find is 775 00:36:57,760 --> 00:36:59,520 something in between that solves the problem. 776 00:36:59,960 --> 00:37:02,520 And I think that that comes to me, it always comes from trying 777 00:37:02,520 --> 00:37:06,120 to understand what will evolve, what I believe it's going to 778 00:37:06,120 --> 00:37:09,080 evolve in my system. And maybe a concrete example, 779 00:37:09,520 --> 00:37:12,520 many years ago I worked for this company and I was part of the 780 00:37:12,560 --> 00:37:14,760 billing team. So we will do everything related 781 00:37:14,760 --> 00:37:18,560 to how we charge the customers up to later calculating the 782 00:37:18,560 --> 00:37:20,360 taxes we had to pay and etcetera. 783 00:37:20,680 --> 00:37:24,640 And it was so complex, right, because the company was offering 784 00:37:24,640 --> 00:37:26,520 a lot of services. There were lots of different 785 00:37:26,520 --> 00:37:30,240 ways to charge the customer, but also to pay for taxes later on. 786 00:37:30,480 --> 00:37:33,640 So we we sort of understood that, you know, charging in 787 00:37:33,640 --> 00:37:37,000 different ways was something that had to be core of this. 788 00:37:37,280 --> 00:37:40,880 And also calculating different ways of taxes was also something 789 00:37:40,880 --> 00:37:43,800 that recorded business. So we spent a lot of time trying 790 00:37:43,800 --> 00:37:46,920 to think of how can we create an obstruction to represent 791 00:37:46,920 --> 00:37:49,160 building and an obstruction to represent taxes. 792 00:37:49,360 --> 00:37:52,600 And it was a huge exercise of us talking to the business people, 793 00:37:52,600 --> 00:37:55,320 understanding the different types of taxes, refining the 794 00:37:55,320 --> 00:37:59,000 abstractions until we got to the point that whenever there was a 795 00:37:59,000 --> 00:38:01,720 new way of charging someone, we would just, you know, implement 796 00:38:01,720 --> 00:38:05,440 a bunch of interfaces and voila, this would plug naturally into 797 00:38:05,440 --> 00:38:07,040 the system. And the same for Texas. 798 00:38:07,400 --> 00:38:10,080 So this is, I think that that was sort of the example I had in 799 00:38:10,080 --> 00:38:13,360 mind when I wrote this chapter about good abstractions, right? 800 00:38:13,360 --> 00:38:16,400 So if you want an abstraction that's truly represents the 801 00:38:16,400 --> 00:38:19,240 intent of the system, because you know the intent of that part 802 00:38:19,240 --> 00:38:21,400 of the system, because you know it will evolve. 803 00:38:21,840 --> 00:38:26,760 And you do this by thinking of how can I give extension points? 804 00:38:26,960 --> 00:38:30,240 How can I facilitate the extension of this design for the 805 00:38:30,240 --> 00:38:31,960 future, right? And I want the person to come 806 00:38:31,960 --> 00:38:35,360 back and write if statement #20 to implement the business rule. 807 00:38:35,360 --> 00:38:37,120 Like I want to simplify this a little bit. 808 00:38:37,600 --> 00:38:39,840 Does that make sense to you? Yeah, yeah. 809 00:38:39,840 --> 00:38:41,440 I mean, in a sense it makes sense. 810 00:38:41,480 --> 00:38:43,120 But some people take to the extreme, right? 811 00:38:43,120 --> 00:38:45,560 They always think in terms of possibilities. 812 00:38:45,560 --> 00:38:48,200 You know, they create too many abstractions sometimes, right? 813 00:38:48,200 --> 00:38:51,160 So I think that kind of like also complicates the software 814 00:38:51,160 --> 00:38:54,120 unnecessarily because sometimes what they predict doesn't really 815 00:38:54,120 --> 00:38:55,760 happen. And some people have this 816 00:38:55,760 --> 00:38:57,800 principle, Yagni, right? You ain't going to need it. 817 00:38:57,800 --> 00:39:01,200 So how to find the balance between good enough abstractions 818 00:39:01,200 --> 00:39:04,520 and maybe too many abstractions? Yeah, but the best thing would 819 00:39:04,520 --> 00:39:06,280 be to have a crystal ball, right? 820 00:39:06,280 --> 00:39:09,400 So we could predict precisely what will change and what will 821 00:39:09,400 --> 00:39:12,280 what change. And we make mistakes for both 822 00:39:12,280 --> 00:39:14,880 sides, right? So we sometimes over design and 823 00:39:14,880 --> 00:39:17,560 we create something more complex for something that doesn't have 824 00:39:17,560 --> 00:39:19,920 to be complex. And other times we under design. 825 00:39:19,920 --> 00:39:21,560 So we create something too simplistic. 826 00:39:22,280 --> 00:39:25,120 And I think of course experience is something that helps. 827 00:39:25,320 --> 00:39:28,240 As time goes by, you learn better to listen to your 828 00:39:28,400 --> 00:39:31,800 requirements, product manager person and then understand if 829 00:39:31,800 --> 00:39:33,120 you need an abstraction there or not. 830 00:39:33,400 --> 00:39:35,360 The other one is you try to observe. 831 00:39:35,480 --> 00:39:38,000 So you start very simple. Don't over complicate some of 832 00:39:38,000 --> 00:39:40,880 the beginning unless you have a clear reason for it. 833 00:39:41,320 --> 00:39:43,880 And then as you go, then you had an abstraction. 834 00:39:44,280 --> 00:39:47,160 But something that I also say in my book that is, I feel like we 835 00:39:47,160 --> 00:39:51,720 said so much, don't over design, don't over design, don't over 836 00:39:51,720 --> 00:39:53,320 design that I should. The main reason, the main 837 00:39:53,320 --> 00:39:55,920 problem right now is that we are under designing things more than 838 00:39:55,920 --> 00:39:59,360 over designing things, right? So a joke that I always make 839 00:39:59,360 --> 00:40:02,160 with my friends was I never saw a person saying, you know, 840 00:40:02,200 --> 00:40:05,120 calling the wife or the husband or or the significant one and 841 00:40:05,120 --> 00:40:08,360 saying, Hey, honey, I'm I'm stuck here at job because, you 842 00:40:08,360 --> 00:40:11,760 know, this code is full of beautiful interfaces and 843 00:40:11,760 --> 00:40:13,880 etcetera. It's usually the other year 844 00:40:13,880 --> 00:40:15,800 round, right? Hey, honey, I'm late because 845 00:40:15,800 --> 00:40:19,120 this code has 3000 lines of code with no single abstraction that 846 00:40:19,120 --> 00:40:21,040 I can understand. I have to guess them from the 847 00:40:21,040 --> 00:40:24,480 implementation. So I also feel we we are always 848 00:40:24,480 --> 00:40:26,400 spending, you know, we go to the extreme. 849 00:40:26,400 --> 00:40:27,920 So you got to find the midterm there. 850 00:40:27,920 --> 00:40:30,480 So, and I even say this explicitly in the book, don't be 851 00:40:30,480 --> 00:40:34,160 afraid of sometimes doing over design because if you feel like 852 00:40:34,160 --> 00:40:36,880 this is going to meet an extension point in the future, 853 00:40:36,880 --> 00:40:38,640 go for it. Don't be afraid of that. 854 00:40:39,360 --> 00:40:41,800 Yeah, like you mentioned, maybe we do need a crystal ball, 855 00:40:41,840 --> 00:40:43,720 right? But I think the essence of the 856 00:40:43,720 --> 00:40:45,600 your advice here, don't be afraid, right? 857 00:40:45,600 --> 00:40:48,160 Sometimes I think we will make mistakes in terms of our 858 00:40:48,160 --> 00:40:50,560 abstractions. The key here is to refactor it, 859 00:40:50,560 --> 00:40:52,240 right? Make changes whenever you 860 00:40:52,280 --> 00:40:54,920 understand the problem better and you find a better way of 861 00:40:54,920 --> 00:40:57,440 designing it right. And again, having good test 862 00:40:57,440 --> 00:41:00,160 cases that covers not just the unit test but also maybe 863 00:41:00,160 --> 00:41:03,480 integration or acceptance test can actually help you in order 864 00:41:03,480 --> 00:41:06,880 to make these redesigns. So the next is about handling 865 00:41:06,880 --> 00:41:09,600 external dependencies or infrastructure, so things like 866 00:41:09,600 --> 00:41:13,000 database calls, web service or maybe other things that you 867 00:41:13,000 --> 00:41:16,240 depend on. So why do you think we should 868 00:41:16,240 --> 00:41:18,600 manage all these external things better? 869 00:41:19,360 --> 00:41:22,800 Yeah, good question. So no systems leaving the 870 00:41:22,800 --> 00:41:24,280 vacuum, right? At some point you're going to 871 00:41:24,280 --> 00:41:28,240 have to integrate to another system being a database or web 872 00:41:28,240 --> 00:41:31,320 service, so on and so forth. And so they have to find ways to 873 00:41:31,320 --> 00:41:35,240 connect your beautiful object oriented design to an external 874 00:41:35,240 --> 00:41:37,560 system that speaks a different language, that has a different 875 00:41:37,560 --> 00:41:40,360 abstraction than you have. If you don't think so much about 876 00:41:40,360 --> 00:41:43,240 it and let's say you just code everything in one big class and 877 00:41:43,240 --> 00:41:46,400 etcetera, suddenly you're very dependent on that abstraction on 878 00:41:46,400 --> 00:41:48,240 that system. If that system changes, it's 879 00:41:48,240 --> 00:41:51,600 going to propagate a lot of changes to you, harder to test, 880 00:41:51,800 --> 00:41:55,440 so on and so forth. So you have to explicitly think 881 00:41:55,440 --> 00:41:58,080 about the external systems, external dependencies, and how 882 00:41:58,080 --> 00:42:01,080 you handle them. And I give a few tips in the 883 00:42:01,080 --> 00:42:03,920 book, and the first one is, I find it quite simple actually to 884 00:42:03,920 --> 00:42:06,480 do is separate infrastructure from the main code. 885 00:42:06,480 --> 00:42:08,760 Whenever you're going to have to talk to a third party, let's say 886 00:42:08,760 --> 00:42:11,080 a database, just don't do this in the same place as the 887 00:42:11,080 --> 00:42:13,720 business rules. Just create another class whose 888 00:42:13,720 --> 00:42:17,080 only responsibility is to translate your domain entity to 889 00:42:17,080 --> 00:42:19,680 a database call, let's say, move it to somewhere else. 890 00:42:20,440 --> 00:42:23,880 Don't let them stay together. That will already improve a lot. 891 00:42:24,200 --> 00:42:26,240 If there's a change in your database, you just have to 892 00:42:26,240 --> 00:42:28,320 change one point, right? You just go to your database 893 00:42:28,320 --> 00:42:31,800 size and you just change there your entities and your domain is 894 00:42:31,800 --> 00:42:34,960 more testable because it's easier for you to replace that 895 00:42:34,960 --> 00:42:37,720 small part of the system that is a database with a mock, for 896 00:42:37,720 --> 00:42:40,720 example. So only advantages there. 897 00:42:40,800 --> 00:42:44,200 I also make a discussion. That is because I feel like 898 00:42:44,320 --> 00:42:47,640 sometimes you read books, people on the Internet saying you 899 00:42:47,640 --> 00:42:51,360 should hide the external infrastructure as much as 900 00:42:51,360 --> 00:42:54,760 possible from everywhere else. Like your code should not know 901 00:42:54,760 --> 00:42:57,880 if you're using a relational database, your code should not 902 00:42:57,880 --> 00:42:59,480 know. You know that you're using a no 903 00:42:59,480 --> 00:43:02,240 SQL database, whatever. And I feel like this is such a 904 00:43:02,240 --> 00:43:04,800 bad advice, right? Because if you really want to 905 00:43:04,800 --> 00:43:07,960 write something that is fully agnostic of the many 906 00:43:07,960 --> 00:43:11,040 technologies you have to choose to deliver software, you're 907 00:43:11,040 --> 00:43:12,920 going to have to write so much code. 908 00:43:13,360 --> 00:43:16,600 And it's way more complex and way more likely to have a bug 909 00:43:16,600 --> 00:43:19,040 and probably doesn't use your infrastructure to the best. 910 00:43:19,040 --> 00:43:21,920 Because if you create something like a mustacre, sort of, you 911 00:43:21,920 --> 00:43:24,040 know, letting down everything else. 912 00:43:24,040 --> 00:43:26,160 And I understand where this comes from, right? 913 00:43:26,160 --> 00:43:28,760 Because back to my first point here, you don't want to make 914 00:43:28,760 --> 00:43:32,560 your code really coupled to the external party, but there's a 915 00:43:32,680 --> 00:43:35,200 limit there. And usually my argument in the 916 00:43:35,200 --> 00:43:37,800 book that I make is what you need to do is you, you have to 917 00:43:37,960 --> 00:43:40,600 hide those decisions from the code, but not from the developer 918 00:43:40,600 --> 00:43:42,320 that is maintaining that code, right? 919 00:43:42,320 --> 00:43:44,960 So the developer knows it's, you know, a relational database 920 00:43:44,960 --> 00:43:48,040 behind the scenes. So, you know, you can use all 921 00:43:48,040 --> 00:43:50,400 the advantages that relational databases give to you. 922 00:43:50,760 --> 00:43:53,240 But if you look at the code, the code of course knows it's a 923 00:43:53,240 --> 00:43:55,960 relational database with a lot of it is a little bit abstract 924 00:43:55,960 --> 00:43:57,320 the way. So you just make a call, you 925 00:43:57,320 --> 00:44:00,520 know, my repuls will not say someday you hit this from the 926 00:44:00,520 --> 00:44:03,320 client code a little bit, but you're not really hiding it 927 00:44:03,320 --> 00:44:05,520 completely. The developer knows, it's really 928 00:44:05,520 --> 00:44:07,800 clear that it's a relational database behind the scenes. 929 00:44:08,240 --> 00:44:11,200 So that is my main point there, that you have to separate these 930 00:44:11,200 --> 00:44:14,760 things, but you're not pretend you don't know them, you know 931 00:44:14,760 --> 00:44:16,160 them. And it's good that you know 932 00:44:16,160 --> 00:44:18,640 them, because you can take optimal decisions, right? 933 00:44:19,480 --> 00:44:21,000 Yeah. So I think that's a very, very 934 00:44:21,000 --> 00:44:23,440 important point, right? Separate infrastructure from 935 00:44:23,440 --> 00:44:25,320 domain code or your business logic, right. 936 00:44:25,320 --> 00:44:27,760 So I think again, coming back to domain driven design, this is 937 00:44:27,760 --> 00:44:29,600 one of the key principles as well. 938 00:44:29,960 --> 00:44:32,840 And I find that design patterns such as hexagonal or ports and 939 00:44:32,840 --> 00:44:36,160 adapter kind of a pattern, right, fits nicely into this, 940 00:44:36,160 --> 00:44:39,000 right, If you follow that principle along. 941 00:44:39,000 --> 00:44:42,040 So you will tend to separate the infrastructure from the business 942 00:44:42,040 --> 00:44:43,720 domain. And I think, yeah, what you 943 00:44:43,720 --> 00:44:46,880 mentioned about don't try to hide too many things, right? 944 00:44:46,880 --> 00:44:49,400 Because sometimes, especially in my previous experience, right, 945 00:44:49,400 --> 00:44:52,320 sometimes even your relational database, right, could use 946 00:44:52,320 --> 00:44:56,000 multiple read replicas, right? And hence it becomes eventual 947 00:44:56,000 --> 00:44:58,240 consistency. So I think if you try to hide 948 00:44:58,240 --> 00:44:59,840 it, it's very, very difficult, right? 949 00:45:00,160 --> 00:45:03,240 And hence I think it's a very, it's actually OK to actually 950 00:45:03,280 --> 00:45:06,600 reveal this, but maybe not in your business domain logic, 951 00:45:06,600 --> 00:45:08,480 right? So I think try to create an 952 00:45:08,520 --> 00:45:10,800 abstraction such that the developers can actually 953 00:45:10,800 --> 00:45:13,360 understand what is going on. So the last one is about 954 00:45:13,360 --> 00:45:16,600 modularization. So I think maybe once you create 955 00:45:16,960 --> 00:45:19,400 an aggregate or bounded context, right, you probably create a 956 00:45:19,400 --> 00:45:21,960 modules or sometimes also packages, right, if you want to 957 00:45:22,240 --> 00:45:24,360 distribute your SDK or something like that. 958 00:45:24,680 --> 00:45:28,600 So I think one very, very useful tips that you write in the book 959 00:45:28,600 --> 00:45:32,480 is about deep modules. So tell us what is this deep 960 00:45:32,480 --> 00:45:34,440 module is all about? Yeah. 961 00:45:34,760 --> 00:45:38,240 So the chapter of the book was there to uncover the problem 962 00:45:38,240 --> 00:45:41,720 that is sometimes your different domains, they grow very much, 963 00:45:42,040 --> 00:45:43,680 right? And then maybe back to the 964 00:45:43,680 --> 00:45:46,000 example of billing. And then maybe let's say billing 965 00:45:46,000 --> 00:45:48,440 is dozens of classes to make billing and then they also have 966 00:45:48,440 --> 00:45:50,320 text. And then maybe you also have 967 00:45:50,320 --> 00:45:53,600 systems that, you know, notify people that send them invoices 968 00:45:53,600 --> 00:45:56,800 via e-mail and whatever. And all those domains, they grow 969 00:45:56,800 --> 00:45:59,120 very fast. Maybe you even want different 970 00:45:59,120 --> 00:46:01,480 teams working on them because you're that big right now. 971 00:46:01,480 --> 00:46:03,840 You know, how do you make these modules to communicate each 972 00:46:03,840 --> 00:46:04,680 other? Because although they are 973 00:46:04,680 --> 00:46:06,440 isolated, they still depend on each other. 974 00:46:06,440 --> 00:46:08,840 You know, billing might send a message to text and billing 975 00:46:08,840 --> 00:46:11,160 might send a message to notifications, whatever. 976 00:46:11,720 --> 00:46:15,240 So this is to me the moment where you need modularization. 977 00:46:15,680 --> 00:46:19,560 And I copied the term deep modules from John from the 978 00:46:19,760 --> 00:46:22,520 Philosophy of Software Design because I really loved that 979 00:46:22,560 --> 00:46:24,720 term. But I think I, I rephrased it a 980 00:46:24,720 --> 00:46:26,880 little bit to my own point of view. 981 00:46:27,160 --> 00:46:30,600 That is, I feel like something we want to for sure come back is 982 00:46:30,600 --> 00:46:33,400 that idea that everything needs to be a module, right? 983 00:46:33,400 --> 00:46:35,640 You don't want to have 1,000,000 modules or 1,000,000 micro 984 00:46:35,640 --> 00:46:38,880 services because it also does whenever you speak stuff, you 985 00:46:38,880 --> 00:46:40,600 win something but you also lose something. 986 00:46:40,600 --> 00:46:42,200 So you want to find the right trade off there. 987 00:46:42,560 --> 00:46:46,600 And deep modules is basically the idea that what you want is a 988 00:46:46,600 --> 00:46:51,160 module needs to do something very big, so to say in quotes, 989 00:46:51,600 --> 00:46:53,240 right? It has to have like a beefy 990 00:46:53,240 --> 00:46:55,880 responsibility. Like for example, this is the 991 00:46:55,880 --> 00:46:59,400 entire billing domain. This is 1 module that I have, so 992 00:46:59,400 --> 00:47:01,240 it is not just one class, you know one class. 993 00:47:01,240 --> 00:47:03,920 It should not be a module in most cases. 994 00:47:04,320 --> 00:47:06,800 So it does something really busy, really important for the 995 00:47:06,800 --> 00:47:10,560 business and it also offers a very simple layer that 996 00:47:10,560 --> 00:47:14,200 simplifies all the complexity that is inside of that module. 997 00:47:14,640 --> 00:47:17,040 This is the type of module you want to have in your system, 998 00:47:17,160 --> 00:47:20,120 right? Complex stuff that is exposed to 999 00:47:20,120 --> 00:47:23,480 the outside in the simplest way possible. 1000 00:47:23,800 --> 00:47:26,960 So that is the idea, so that the clients, others that want to 1001 00:47:26,960 --> 00:47:29,800 communicate with their module, they have to do the least amount 1002 00:47:29,800 --> 00:47:32,520 of effort to be able to send you a message. 1003 00:47:33,000 --> 00:47:35,000 And I think this is where, to be honest, where the challenge 1004 00:47:35,000 --> 00:47:38,840 starts because it's creating a simple interface on top of 1005 00:47:38,840 --> 00:47:41,040 something very complex. It's tricky. 1006 00:47:41,600 --> 00:47:44,520 I can't remember now that it's in my book or in John's book or 1007 00:47:44,520 --> 00:47:47,400 maybe in both that there are ideas, you know, like come up 1008 00:47:47,400 --> 00:47:50,280 with sensible defaults, right? You don't have to force your 1009 00:47:50,280 --> 00:47:54,880 client to have to configure every single possible variable 1010 00:47:55,160 --> 00:47:57,760 that you have in there. So for example, this is one 1011 00:47:57,760 --> 00:48:00,680 example. Simplify things and this is 1012 00:48:00,680 --> 00:48:02,760 where you need design again, right? 1013 00:48:03,520 --> 00:48:05,200 Yeah. So I think deep modules here, I 1014 00:48:05,200 --> 00:48:07,840 really like it, right? Because sometimes when we create 1015 00:48:07,840 --> 00:48:11,200 modules, we don't really think about the interfaces of the API 1016 00:48:11,200 --> 00:48:14,080 or the contracts, right. So I think the key essence here 1017 00:48:14,080 --> 00:48:17,040 is like simple interface. So you abstract away all the 1018 00:48:17,040 --> 00:48:19,760 inner details by exposing those simple interface. 1019 00:48:20,120 --> 00:48:22,800 And yeah, in in fact the complexities is hidden inside 1020 00:48:22,800 --> 00:48:24,840 the module. And I think a few other things 1021 00:48:24,840 --> 00:48:28,400 that I also like in the modularization part is actually 1022 00:48:28,680 --> 00:48:31,360 think of like the module, even though you build it within your 1023 00:48:31,360 --> 00:48:33,600 own team, right? You should think as if like 1024 00:48:33,600 --> 00:48:36,120 you're going to publish it to another team or another company, 1025 00:48:36,120 --> 00:48:39,000 which is beyond your control. And you cannot kind of like give 1026 00:48:39,000 --> 00:48:41,680 them a close guidance. And the last thing, of course, 1027 00:48:41,680 --> 00:48:45,240 like don't leak out the inner details, maybe like your 1028 00:48:45,240 --> 00:48:47,280 database tables, columns and things like that. 1029 00:48:47,280 --> 00:48:49,320 So I think that's definitely a bad practice. 1030 00:48:49,720 --> 00:48:52,560 So Mauricio, thank you for giving us the walkthrough of the 1031 00:48:52,560 --> 00:48:54,880 six principles. Again, there are so many things 1032 00:48:54,880 --> 00:48:57,120 in your book. So for people who love this 1033 00:48:57,120 --> 00:49:00,000 conversation so far, I'm sure you'll get a lot more insights 1034 00:49:00,000 --> 00:49:02,680 by reading the book again, the book is not a thick book, right? 1035 00:49:02,680 --> 00:49:05,800 So probably it's like 150 pages. Like what Mauricio said. 1036 00:49:06,040 --> 00:49:07,920 You can actually finish it in a few days. 1037 00:49:08,160 --> 00:49:11,800 So please do check it out. I think I find this book, even 1038 00:49:11,800 --> 00:49:15,520 though sounds simplistic, but looking at my career experience, 1039 00:49:15,520 --> 00:49:17,920 right, this is not something that is commonly practiced. 1040 00:49:18,400 --> 00:49:20,480 So I think in the last part of your book, you also mentioned 1041 00:49:20,480 --> 00:49:23,400 about being pragmatic. So one particular thing that I 1042 00:49:23,400 --> 00:49:27,160 love about being pragmatic is you talk about for us to do this 1043 00:49:27,160 --> 00:49:31,000 simple object oriented design because we owe this to our 1044 00:49:31,000 --> 00:49:33,640 junior developers. I find this quite beautiful 1045 00:49:33,640 --> 00:49:35,600 message. So maybe if you can enlighten us 1046 00:49:35,600 --> 00:49:37,840 a little bit about this. For sure. 1047 00:49:38,320 --> 00:49:41,120 So whenever you're coding and you're trying to be pragmatic, 1048 00:49:41,520 --> 00:49:43,800 remember that at some point there will be a junior developer 1049 00:49:43,800 --> 00:49:47,200 that will maintain this. So it is our duty to make sure 1050 00:49:47,440 --> 00:49:49,760 they can learn from the code we're writing, right? 1051 00:49:49,880 --> 00:49:52,240 When I was a junior developer, I was learning a lot from what I 1052 00:49:52,240 --> 00:49:54,440 was reading. So you own this, the junior 1053 00:49:54,440 --> 00:49:57,320 developer, you're directly, you're indirectly training. 1054 00:49:57,800 --> 00:49:59,160 So that was sort of the gist there. 1055 00:49:59,400 --> 00:50:01,800 I'm really happy like this. Yeah. 1056 00:50:02,160 --> 00:50:03,840 So I think the onus is on us, right? 1057 00:50:03,840 --> 00:50:07,720 So every time we leave the code behind because the code tends to 1058 00:50:07,720 --> 00:50:09,040 leave for quite some time, right? 1059 00:50:09,040 --> 00:50:11,440 You don't always rewrite everything every time. 1060 00:50:11,760 --> 00:50:14,120 So I think the next developer who comes in and try to 1061 00:50:14,120 --> 00:50:17,480 understand your code will refer to your code design and most 1062 00:50:17,480 --> 00:50:18,720 likely they will just build on top. 1063 00:50:19,000 --> 00:50:21,280 So if you have a messy code, obviously they will learn a 1064 00:50:21,280 --> 00:50:24,400 messy thing and maybe they'll bring it forward to another 1065 00:50:24,440 --> 00:50:26,480 projects or software that they are working on. 1066 00:50:26,800 --> 00:50:30,080 So I think the cycle continues and hence we probably have a 1067 00:50:30,080 --> 00:50:31,920 bigger problem in the software industry. 1068 00:50:32,400 --> 00:50:34,920 So thanks for this conversation. Mauricio, I have one last 1069 00:50:34,920 --> 00:50:38,160 question which I asked you last time in our conversation before, 1070 00:50:38,160 --> 00:50:39,840 right? I call this the three tech 1071 00:50:39,880 --> 00:50:43,080 leadership wisdom. So I'd like to hear again from 1072 00:50:43,080 --> 00:50:45,120 you if you have a different wisdom this time. 1073 00:50:45,880 --> 00:50:51,040 Yeah, good question and I will try to give suggestion based on 1074 00:50:51,040 --> 00:50:53,000 the discussion today. So I guess it will be a bit 1075 00:50:53,000 --> 00:50:56,480 different from the previous one. So the first one is focus on 1076 00:50:56,480 --> 00:50:59,320 your technical debts because at some point it can become 1077 00:50:59,320 --> 00:51:02,640 impossible to pay. So everything that we discussed 1078 00:51:02,640 --> 00:51:06,600 of refector early and etcetera, I truly believe it makes a 1079 00:51:06,600 --> 00:51:09,440 difference in practice. Then focus on quality. 1080 00:51:09,440 --> 00:51:12,000 So OK, that's not so different from the first conversation we 1081 00:51:12,000 --> 00:51:14,160 had, Harry, but I guess I like quality. 1082 00:51:14,560 --> 00:51:17,960 Don't let it be a second class citizen in the process, right? 1083 00:51:18,000 --> 00:51:20,520 Find ways to make sure quality is just part of the process, 1084 00:51:20,520 --> 00:51:23,120 part of the culture. And finally, something that is a 1085 00:51:23,120 --> 00:51:26,480 lot on my mind right now, given the team that I'm working with, 1086 00:51:27,040 --> 00:51:30,400 is focus on developer experience. 1087 00:51:30,840 --> 00:51:33,520 Because coding should be fun and fast. 1088 00:51:33,520 --> 00:51:37,800 It's not boring and slow, but once you grow, it is very hard 1089 00:51:37,800 --> 00:51:40,160 to keep things that way. So they have to put some energy 1090 00:51:40,160 --> 00:51:42,320 there. Yes, I think developer 1091 00:51:42,320 --> 00:51:44,840 experience is top of mind. It's quite a hot topic these 1092 00:51:44,840 --> 00:51:47,120 days, right? So many publications around it. 1093 00:51:47,360 --> 00:51:50,000 So definitely simple object oriented design or simple 1094 00:51:50,000 --> 00:51:52,680 software design, right, will help a lot in terms of developer 1095 00:51:52,680 --> 00:51:54,920 experience as well. Because code that is easily 1096 00:51:54,920 --> 00:51:58,200 understandable, gives a lot of pleasure and creates flow 1097 00:51:58,200 --> 00:51:59,640 whenever you work on that software. 1098 00:52:00,040 --> 00:52:03,280 So for people who love this conversation, they want to check 1099 00:52:03,280 --> 00:52:06,080 out with you online or they want to buy the book, is there a 1100 00:52:06,080 --> 00:52:12,320 place where they can find you? For sure I'm on Twitter X my 1101 00:52:12,320 --> 00:52:16,440 name and surname all together. Feel free to add me on link 10. 1102 00:52:16,960 --> 00:52:20,720 My website mauriceandnishi.com has a lot of information there, 1103 00:52:20,880 --> 00:52:22,840 including a link to the website of the book. 1104 00:52:23,240 --> 00:52:25,160 Those are the main ones for sure that I use. 1105 00:52:25,840 --> 00:52:27,880 All right. Thanks again, Mauricio for this 1106 00:52:27,880 --> 00:52:30,800 second episode. So I'm looking forward for next 1107 00:52:30,800 --> 00:52:33,040 conversation that we have. So I'm sure we'll learn. 1108 00:52:33,120 --> 00:52:35,600 We'll definitely learn a lot of things as well. 1109 00:52:35,600 --> 00:52:37,560 So thanks again. Thank you the.