1 00:00:00,040 --> 00:00:05,160 When I started back decades ago, you probably didn't need an 2 00:00:05,160 --> 00:00:07,520 evolutionary architecture because technology was not 3 00:00:07,520 --> 00:00:10,880 moving that quickly. Expectations were not moving 4 00:00:10,880 --> 00:00:14,640 that quickly. But what we see now is that 5 00:00:15,000 --> 00:00:17,440 business model lifetimes are shorter. 6 00:00:17,880 --> 00:00:21,520 Consumer expectations for businesses are being driven by 7 00:00:21,960 --> 00:00:25,960 what's happening in TikTok. And when you have that level of 8 00:00:25,960 --> 00:00:30,920 change, having a system that you can't change to reflect what it 9 00:00:30,920 --> 00:00:34,120 is that your customers are demanding you give them is not 10 00:00:34,120 --> 00:00:36,560 going to allow you to succeed as an organization. 11 00:00:36,880 --> 00:00:41,640 One aspect of architecture that I think is important is it 12 00:00:41,640 --> 00:00:46,640 depends on what is important to that organization. 13 00:00:47,000 --> 00:00:53,000 You want your architecture to support the things that matter. 14 00:00:53,480 --> 00:00:56,600 There is nothing inherently wrong with the monolith. 15 00:00:57,320 --> 00:01:00,080 Yes, there are some things that you can do with the microservice 16 00:01:00,080 --> 00:01:03,440 that you can't do with the monolith, but then there are 17 00:01:03,440 --> 00:01:10,040 problems that you can't have in a monolith that you have to deal 18 00:01:10,040 --> 00:01:11,760 with in a microservices architecture. 19 00:01:12,200 --> 00:01:17,200 People try to fight Conroy's Law and you just can't do it. 20 00:01:17,400 --> 00:01:21,320 If the people don't talk effectively to each other, the 21 00:01:21,320 --> 00:01:25,960 systems that they're responsible for or not going to talk to each 22 00:01:25,960 --> 00:01:28,280 other. There was one study that was 23 00:01:28,280 --> 00:01:32,880 done by the code scene people when the coding assistant that 24 00:01:32,880 --> 00:01:35,680 they were working with recommended a refactoring. 25 00:01:36,360 --> 00:01:39,840 In the best case, they were right 37% of the time. 26 00:01:40,440 --> 00:01:44,680 If you as a developer got things wrong 2/3 of the time, you're 27 00:01:44,680 --> 00:01:46,720 not going to keep your job for very long. 28 00:01:59,680 --> 00:02:02,200 Hello everyone, welcome back to another new episode of the Tech 29 00:02:02,200 --> 00:02:04,760 Legional Podcast. Today I'm very excited here to 30 00:02:04,760 --> 00:02:08,960 have an honorary guest. Doctor Rebecca Parsons sees ex 31 00:02:08,960 --> 00:02:11,440 talk work. CTO for a long time, around 15 32 00:02:11,440 --> 00:02:14,040 years, I guess, until very recently as he left the 33 00:02:14,040 --> 00:02:16,960 position. So Doctor Rebecca today is here 34 00:02:16,960 --> 00:02:18,960 to talk about evolutionary architecture. 35 00:02:19,160 --> 00:02:22,000 I think this topic has been around for quite some time, 36 00:02:22,000 --> 00:02:26,160 although I think the adoption has not been really there in the 37 00:02:26,160 --> 00:02:28,480 industry. So Doctor Rebecca, really 38 00:02:28,480 --> 00:02:30,880 looking forward to have this conversation with you today. 39 00:02:30,880 --> 00:02:33,520 I hope to learn a lot about evolutionary architecture. 40 00:02:34,360 --> 00:02:37,680 Happy to be here, Henry. Right, Doctor Rebecca, I always 41 00:02:37,680 --> 00:02:40,960 love to start my conversation by asking my guests to maybe tell 42 00:02:40,960 --> 00:02:43,560 us a little bit more about you, maybe turning points that you 43 00:02:43,560 --> 00:02:47,480 think we all can learn from you. Well, I guess the first one 44 00:02:47,480 --> 00:02:51,720 would be as I was just getting out of university and taking my 45 00:02:51,720 --> 00:02:56,640 first real job. And I had offers at the same 46 00:02:56,640 --> 00:02:59,440 company, but from 2 very different departments because I 47 00:02:59,440 --> 00:03:02,320 have actually both a degree in computer science as well as 48 00:03:02,320 --> 00:03:06,520 degree in economics. And I went through the classic, 49 00:03:06,520 --> 00:03:11,560 OK, pros and cons on the spreadsheet kind of process and 50 00:03:11,560 --> 00:03:14,040 had decided I was going to take the job in economics. 51 00:03:14,040 --> 00:03:15,640 I mean, I thought, you know, what could be better? 52 00:03:15,640 --> 00:03:18,200 If somebody's going to pay me to read the Wall Street Journal, 53 00:03:18,480 --> 00:03:21,960 you know, why wouldn't that be what what I did? 54 00:03:22,400 --> 00:03:26,080 And when I got on the phone talking to the recruiter, I said 55 00:03:26,080 --> 00:03:27,880 I'm going to take the computer science job. 56 00:03:27,920 --> 00:03:30,120 And it's like, wait a minute, you know? 57 00:03:30,880 --> 00:03:34,720 But what I realized is in the back of my head, I'd been 58 00:03:34,720 --> 00:03:37,640 playing with, OK, yes, I'm going to take the economics job. 59 00:03:37,640 --> 00:03:39,640 I'm going to take the computer science job. 60 00:03:40,240 --> 00:03:44,320 And I realized that even though all of the clinical analysis 61 00:03:44,320 --> 00:03:47,360 said I should do the economics job, what I really wanted to do 62 00:03:47,360 --> 00:03:52,200 was the computer science job. And what I learned from that is, 63 00:03:52,360 --> 00:03:54,440 sure, go ahead and do the analysis. 64 00:03:54,440 --> 00:03:58,640 But that process of, OK, I'm going to sit with myself for 65 00:03:58,640 --> 00:04:02,600 half a day as if I've taken the computer science job, and I'm 66 00:04:02,600 --> 00:04:05,200 going to sit with myself for half a day as if I've taken the 67 00:04:05,200 --> 00:04:08,320 economics job. And your gut is going to tell 68 00:04:08,320 --> 00:04:10,320 you what's the right thing to do. 69 00:04:10,320 --> 00:04:13,840 And it's good to listen to your gut. 70 00:04:13,920 --> 00:04:15,880 And, you know, I've often wondered what would have 71 00:04:15,880 --> 00:04:18,360 happened if I had taken the economics job. 72 00:04:18,800 --> 00:04:21,959 I probably would have ended up in law school as a lawyer or 73 00:04:21,959 --> 00:04:25,120 something like that, as opposed to a computer scientist. 74 00:04:25,120 --> 00:04:28,800 But I I'd say that was the first one. 75 00:04:28,800 --> 00:04:33,640 And then the second one, I would say I didn't listen to my gut. 76 00:04:35,200 --> 00:04:40,880 And this was, I had completed my postdoc at Los Alamos and I was 77 00:04:40,880 --> 00:04:45,480 choosing between staying as at Los Alamos as a researcher or 78 00:04:45,480 --> 00:04:48,080 going to the university as a professor. 79 00:04:48,640 --> 00:04:54,320 And when I had first started my PhD full time, I told myself, 80 00:04:54,320 --> 00:04:56,720 I'm never going to be an assistant professor of computer 81 00:04:56,720 --> 00:04:59,400 science and I'm never going to live in the state of Florida. 82 00:05:00,120 --> 00:05:03,840 And I ended up at the University of Central Florida as an 83 00:05:03,840 --> 00:05:05,680 assistant professor of computer science. 84 00:05:06,280 --> 00:05:10,560 And part of the reason I did that academia, at least in in 85 00:05:10,560 --> 00:05:14,720 the US at that time, if you didn't pretty quickly go into 86 00:05:14,720 --> 00:05:17,120 academia, they just didn't take you seriously. 87 00:05:17,120 --> 00:05:21,080 And it was one of those things, OK, if I think I might want to 88 00:05:21,080 --> 00:05:24,800 do this, I need to do it now. But I was right. 89 00:05:25,520 --> 00:05:28,760 Maybe it's because the amount of time I spent in industry, I 90 00:05:28,760 --> 00:05:33,240 don't know. But what I learned is that to 91 00:05:33,240 --> 00:05:38,400 have a success criteria for yourself that isn't aligned with 92 00:05:38,400 --> 00:05:42,200 the success criteria of your organization is a recipe to be 93 00:05:42,200 --> 00:05:46,840 very, very unhappy because either they think you're 94 00:05:46,840 --> 00:05:50,120 successful and you're personally miserable or you feel like 95 00:05:50,120 --> 00:05:52,200 you're successful and they think you're a failure. 96 00:05:52,640 --> 00:05:55,240 And neither one of those is a good place to be. 97 00:05:55,800 --> 00:06:00,160 And then I would say the the third came after I'd been CTO 98 00:06:00,160 --> 00:06:02,880 for a little while and I was having a conversation with our 99 00:06:03,120 --> 00:06:09,520 presidents and CEO and I'd had an experience, I had been on 100 00:06:09,520 --> 00:06:12,440 ACTO panel for the Grace Hopper Celebration of Women in 101 00:06:12,440 --> 00:06:16,800 Computing. And I was the only woman CTO on 102 00:06:16,800 --> 00:06:20,200 the panel, which I thought was kind of ironic for the Grace 103 00:06:20,200 --> 00:06:23,800 Hopper Celebration of Women in Computing, but I, I understood 104 00:06:23,800 --> 00:06:27,920 the rationale for it. But what I learned later is we 105 00:06:27,920 --> 00:06:32,640 had lunch and they had students at the tables with the different 106 00:06:32,640 --> 00:06:35,680 CTOS and all of the other CTOS ended up just talking about jobs 107 00:06:35,680 --> 00:06:39,280 at their company. I was talking with the women 108 00:06:39,400 --> 00:06:43,040 students at my table about their careers and their aspirations 109 00:06:43,040 --> 00:06:45,640 and such. And one of them said to me, I 110 00:06:45,640 --> 00:06:48,600 think I need to leave graduate schools or at least change my 111 00:06:48,600 --> 00:06:52,680 advisor. Because my advisor told me that 112 00:06:52,680 --> 00:06:55,680 I was taking the spot of a man and I needed to go home and make 113 00:06:55,680 --> 00:06:58,960 babies like I was supposed to. And they thought, you know, this 114 00:06:58,960 --> 00:07:02,440 is the 21st century. The fact that anywhere on the 115 00:07:02,440 --> 00:07:06,360 planet, some professor would think it was all right to say 116 00:07:06,360 --> 00:07:08,920 something like that just appalled me. 117 00:07:09,320 --> 00:07:14,600 And I decided during that conversation with Trevor that 118 00:07:14,600 --> 00:07:19,000 that the CEO was that even though I'm actually an 119 00:07:19,000 --> 00:07:22,800 introvert, I don't really like getting up on stages. 120 00:07:23,400 --> 00:07:27,440 But it was important for me to be up on those stages, to be 121 00:07:27,440 --> 00:07:32,320 talking as a technologist, not just talking about diversity, 122 00:07:32,320 --> 00:07:35,720 but talking about Agilent enterprise architecture and 123 00:07:35,720 --> 00:07:39,000 evolutionary architecture and domain specific languages and 124 00:07:39,000 --> 00:07:40,560 all of these different technical talkative. 125 00:07:41,120 --> 00:07:46,040 Because women needed to see someone who looks like me up on 126 00:07:46,040 --> 00:07:48,560 a stage talking about things like that. 127 00:07:49,520 --> 00:07:52,520 And that was a real turning point for me. 128 00:07:52,720 --> 00:07:57,200 Prior to that I'd been on a couple of stages, but it was an 129 00:07:57,200 --> 00:08:01,760 important part of what I did and and it became a very important 130 00:08:01,760 --> 00:08:03,760 part of the job I did for ThoughtWorks. 131 00:08:04,680 --> 00:08:07,200 Wow, thanks for sharing. First of all, I think the story 132 00:08:07,200 --> 00:08:09,400 is really, you know, strong and beautiful, right? 133 00:08:09,400 --> 00:08:11,600 So the first is about listening to your gut, right? 134 00:08:11,600 --> 00:08:14,680 So I could imagine back then you were kind of like torn between 135 00:08:14,680 --> 00:08:17,720 the two or, you know, two majors from your science and economics. 136 00:08:17,720 --> 00:08:20,640 And then after that, it's a lesson about not listening to 137 00:08:20,640 --> 00:08:23,560 your guts. I think sometimes we all did 138 00:08:23,560 --> 00:08:25,520 that as well, especially in our career, right? 139 00:08:25,520 --> 00:08:28,680 We wanted to leave, but we couldn't for whatever reasons, 140 00:08:28,680 --> 00:08:30,800 right, And ended up being miserable in the job. 141 00:08:31,160 --> 00:08:33,440 And the third one is about making a stand, right? 142 00:08:33,480 --> 00:08:36,640 Being there as an inspiration for some women out there. 143 00:08:36,640 --> 00:08:40,000 So thanks for sharing the story. So Doctor Rebecca, you are well 144 00:08:40,000 --> 00:08:41,880 known about evolutionary architecture. 145 00:08:41,880 --> 00:08:44,240 In fact, you have written this book, Building Evolutionary 146 00:08:44,240 --> 00:08:46,160 Architecture, which is in the second edition now. 147 00:08:46,560 --> 00:08:49,600 So maybe first of all, right, tell us a little bit more, why 148 00:08:49,600 --> 00:08:51,240 do we need evolutionary architecture? 149 00:08:51,240 --> 00:08:53,760 Because I think when we talk about architecture, typically 150 00:08:53,760 --> 00:08:56,160 people talk about something that is difficult to change. 151 00:08:56,280 --> 00:08:59,160 And why do we need an evolution for our architecture? 152 00:09:00,040 --> 00:09:05,440 Well, when I started back decades ago, you probably didn't 153 00:09:05,440 --> 00:09:07,800 need an evolutionary architecture because technology 154 00:09:07,800 --> 00:09:11,520 was not moving that quickly. Expectations were not moving 155 00:09:11,520 --> 00:09:15,320 that quickly. But what we see now is that 156 00:09:16,160 --> 00:09:18,640 business model lifetimes are shorter. 157 00:09:19,000 --> 00:09:24,160 Customer expectations for businesses, Consumer 158 00:09:24,160 --> 00:09:28,280 expectations for businesses are being driven not by what's 159 00:09:28,280 --> 00:09:30,880 happening in the financial services industry, but what's 160 00:09:30,880 --> 00:09:35,840 happening in TikTok. And you don't have nearly as 161 00:09:35,840 --> 00:09:41,680 much control over what it is you must build to remain 162 00:09:41,680 --> 00:09:45,360 competitive. And when you have that level of 163 00:09:45,360 --> 00:09:50,280 change, having a system that you can't change to reflect what it 164 00:09:50,280 --> 00:09:53,480 is that your customers are demanding you give them is not 165 00:09:53,480 --> 00:09:55,960 going to allow you to succeed as an organization. 166 00:09:56,360 --> 00:10:00,680 And so with all of the change that is happening around to say, 167 00:10:00,680 --> 00:10:04,280 but oh, the architecture will never change, it will, you know, 168 00:10:04,320 --> 00:10:07,480 that's ridiculous. And we can't really predict 169 00:10:07,480 --> 00:10:09,200 where that change is going to come from. 170 00:10:09,760 --> 00:10:14,440 You can in hindsight look at, for example, virtual machines 171 00:10:14,440 --> 00:10:18,440 and containerization and Docker and you know, and see that as a 172 00:10:18,440 --> 00:10:22,600 natural progression. But the impact on how people 173 00:10:22,600 --> 00:10:27,480 think about their technology estate was incredibly impacted 174 00:10:27,480 --> 00:10:33,160 by Docker and it's ilk in a way really that virtual machines 175 00:10:33,160 --> 00:10:35,160 didn't have that same level of impact. 176 00:10:35,480 --> 00:10:40,200 And so even if you weren't going to use Docker right away, you 177 00:10:40,200 --> 00:10:42,920 have to be thinking about it from an architectural 178 00:10:42,920 --> 00:10:46,400 perspective of how is this something that I can take 179 00:10:46,400 --> 00:10:50,000 advantage of? And so it became a necessity 180 00:10:50,000 --> 00:10:55,120 really, not because anybody wanted it to be, but because you 181 00:10:55,120 --> 00:10:58,280 didn't have a choice. You have to be able to change 182 00:10:58,280 --> 00:11:01,600 your systems to keep up with changing business expectations 183 00:11:01,600 --> 00:11:05,240 and consumer expectations, let alone regulatory frameworks and 184 00:11:05,240 --> 00:11:09,000 things of that nature. Yeah, and also during the 185 00:11:09,000 --> 00:11:11,680 pandemic back then, right? It's a situational impact, 186 00:11:11,680 --> 00:11:13,440 right? Suddenly everyone has to 187 00:11:13,440 --> 00:11:16,840 scramble and find a solution. So I think the other aspect 188 00:11:16,840 --> 00:11:19,960 about architecture that I have seen typically in a start-ups is 189 00:11:19,960 --> 00:11:23,160 that instead of doing evolutionary changes, they make 190 00:11:23,160 --> 00:11:25,760 a revolutionary changes. You know, things like rewrites, 191 00:11:25,960 --> 00:11:27,640 breaking monolith into micro service. 192 00:11:27,880 --> 00:11:31,600 How about this kind of case? Do you see it as also something 193 00:11:31,840 --> 00:11:36,920 that is doable or more advisable to do for, you know, industry or 194 00:11:37,240 --> 00:11:39,800 companies who are changing very, very rapidly? 195 00:11:40,640 --> 00:11:43,560 Well, what one of the goals of having an evolutionary 196 00:11:43,560 --> 00:11:47,160 architecture is simplifying whatever change it is that you 197 00:11:47,200 --> 00:11:51,320 ultimately have to make. And if you've got something 198 00:11:51,320 --> 00:11:53,680 that's small enough and self-contained enough that you 199 00:11:53,680 --> 00:11:56,000 can just throw it away and rewrite it, that's probably 200 00:11:56,000 --> 00:11:58,760 easiest. And you don't have to worry 201 00:11:58,760 --> 00:12:01,680 about being evolutionary if it's only going to run once. 202 00:12:02,000 --> 00:12:05,160 You know, I saw a talk by a scientist from the Jet 203 00:12:05,160 --> 00:12:09,880 Propulsion Laboratory in the US and the the purpose of the talk 204 00:12:09,880 --> 00:12:14,040 was to talk about how they took advantage of cloud to do this 205 00:12:14,040 --> 00:12:17,120 particular analysis. But the point I took away from 206 00:12:17,120 --> 00:12:20,800 it is the fact that this data download was only ever going to 207 00:12:20,800 --> 00:12:24,040 happen once and you would never have to run it again. 208 00:12:24,680 --> 00:12:29,160 No, you don't worry about evolving something that will 209 00:12:29,160 --> 00:12:32,520 only run once. You know, you get it to the 210 00:12:32,520 --> 00:12:35,920 point that you need it to let it run once and then you throw it 211 00:12:35,920 --> 00:12:38,880 away. But the problem is when you look 212 00:12:38,880 --> 00:12:44,520 at most of the enterprises out there that have been around for 213 00:12:44,520 --> 00:12:48,080 any length of time, they don't have pieces of their 214 00:12:48,080 --> 00:12:50,320 architecture that they can just throw away. 215 00:12:50,680 --> 00:12:55,200 They probably have 5 or 6 generations of technology and 216 00:12:55,200 --> 00:12:58,680 languages and frameworks and all of that kind of stuff. 217 00:12:59,280 --> 00:13:05,880 And so you have to start by getting yourself in a position 218 00:13:05,880 --> 00:13:09,760 where maybe you do have things that you can throw away, but 219 00:13:09,760 --> 00:13:13,080 for, for a lot of enterprises, that isn't the case. 220 00:13:13,120 --> 00:13:15,880 Sure, if you're a startup, if you're a mom and pop, if you've 221 00:13:15,880 --> 00:13:19,640 been running on a, on an Access database or an Excel, Excel 222 00:13:19,640 --> 00:13:24,400 spreadsheet or you know what, whatever, maybe you can do that. 223 00:13:24,840 --> 00:13:27,880 Maybe you haven't customized yourself into a corner or 224 00:13:27,880 --> 00:13:31,960 something like that. But for a lot of the kinds of 225 00:13:32,400 --> 00:13:35,640 clients that we dealt with at ThoughtWorks, that just wasn't 226 00:13:35,640 --> 00:13:38,400 the reality. They didn't have pieces of their 227 00:13:38,400 --> 00:13:40,320 architecture they could just throw away. 228 00:13:41,200 --> 00:13:44,560 So maybe in your definition, what do you define as an 229 00:13:44,560 --> 00:13:46,600 architecture? Because when I talk to, you 230 00:13:46,600 --> 00:13:48,440 know, when I learn about architecture in so many 231 00:13:48,440 --> 00:13:51,040 different resources and books, right, the first thing that we 232 00:13:51,040 --> 00:13:54,000 often hear about is about, you know, architecture is stuff that 233 00:13:54,000 --> 00:13:57,560 is hard to change or you make until the last responsible 234 00:13:57,560 --> 00:13:59,280 moment, right? Or the other thing. 235 00:13:59,320 --> 00:14:01,440 But like Neil Fault always say architecture is about 236 00:14:01,440 --> 00:14:03,400 trade-offs, right? Is there's always something that 237 00:14:03,400 --> 00:14:05,480 you trade off. So maybe in your definition 238 00:14:05,480 --> 00:14:07,840 before we actually go into the evolutionary aspect. 239 00:14:08,080 --> 00:14:10,280 So what is architecture in your definition? 240 00:14:11,200 --> 00:14:16,040 I work very hard never to precisely define it. 241 00:14:16,400 --> 00:14:20,760 Part of the problem is I'm an academic and I can't call it a 242 00:14:20,760 --> 00:14:24,840 definition unless it very clearly includes things and very 243 00:14:25,160 --> 00:14:29,880 clearly excludes things. But one aspect of architecture 244 00:14:29,960 --> 00:14:36,840 that I think is important is it depends on what is important to 245 00:14:36,840 --> 00:14:41,840 that organization. You want your architecture to 246 00:14:42,040 --> 00:14:45,960 support the things that matter and that that this is where Neil 247 00:14:45,960 --> 00:14:49,360 starts to get into the trade off discussion because you might 248 00:14:49,360 --> 00:14:51,920 have two things that are important to you, but you have 249 00:14:51,920 --> 00:14:54,120 to decide which one is going to take precedent. 250 00:14:54,480 --> 00:14:57,960 Well, there are also things that are not important like that Jet 251 00:14:57,960 --> 00:15:04,160 Propulsion Laboratory program. It had absolutely no need to be 252 00:15:04,520 --> 00:15:08,920 maintainable or recoverable because they had one data set. 253 00:15:08,920 --> 00:15:10,640 They were going to run it once and then there. 254 00:15:11,640 --> 00:15:17,760 And so the characteristics that lead to the success or failure 255 00:15:17,760 --> 00:15:21,360 of your system, those are the architectural characteristics. 256 00:15:21,600 --> 00:15:28,280 It might be network security, data performance, operability, 257 00:15:28,280 --> 00:15:30,640 resilience, I mean there are all kinds of different 258 00:15:30,640 --> 00:15:33,840 characteristics. When Neil and I give this talk, 259 00:15:33,920 --> 00:15:38,440 we've got a screenshot we took actually when we the 1st edition 260 00:15:38,440 --> 00:15:40,120 came out. And so it's quite all that. 261 00:15:40,200 --> 00:15:44,080 It doesn't, for example, have observability on it, but there 262 00:15:44,080 --> 00:15:47,640 are, you know, dozens of different elodies. 263 00:15:48,160 --> 00:15:51,920 And for each one of those elodies, there's a system that 264 00:15:51,920 --> 00:15:55,720 it matters for. But not every system needs to 265 00:15:55,720 --> 00:15:58,080 worry about all of them. And in fact, you can't because 266 00:15:58,080 --> 00:16:00,160 many of them are mutually inconsistent. 267 00:16:00,680 --> 00:16:05,080 And So what we, what I talk about in terms of architectures, 268 00:16:05,080 --> 00:16:10,600 what are the things that are of importance in your industry for 269 00:16:10,600 --> 00:16:13,840 this particular system and even for your particular 270 00:16:13,840 --> 00:16:17,440 organization, because organizations have particular 271 00:16:17,440 --> 00:16:20,280 challenges. You know, retailer A might not 272 00:16:20,280 --> 00:16:23,640 have this the the same perspective on everything that 273 00:16:23,640 --> 00:16:26,040 retailer B does. So they're, they're in the same 274 00:16:26,040 --> 00:16:27,320 industry. They might be in the same 275 00:16:27,320 --> 00:16:30,760 geography, but that doesn't mean that they worry about the same 276 00:16:30,760 --> 00:16:33,320 things. Right, definitely makes sense, 277 00:16:33,320 --> 00:16:34,960 right. So something that is most 278 00:16:34,960 --> 00:16:37,520 important to you, right? You define that as like the 279 00:16:37,520 --> 00:16:39,560 so-called attributes of your architecture. 280 00:16:39,880 --> 00:16:43,240 And from there we kind of like evolve as and when there's a 281 00:16:43,240 --> 00:16:44,960 change, as and when there's a need, right. 282 00:16:45,320 --> 00:16:48,120 So one thing in particular that about evolutionary architecture, 283 00:16:48,120 --> 00:16:51,440 even though this resource, the book you know and the theory has 284 00:16:51,440 --> 00:16:54,600 been around for quite some time, I actually rarely listen people 285 00:16:54,600 --> 00:16:57,360 talking about evolutionary architecture in the industry for 286 00:16:57,400 --> 00:17:00,280 whatever reasons. Maybe it's because I'm not 287 00:17:00,280 --> 00:17:03,280 exposed in those kind of conversations, but in your view, 288 00:17:03,280 --> 00:17:05,880 what is the state of adoption in the industry actually? 289 00:17:06,839 --> 00:17:11,040 I would say that it is not widely adopted in the way, say 290 00:17:11,040 --> 00:17:14,000 micro services are because, you know, even if you don't have a 291 00:17:14,000 --> 00:17:17,400 micro service, people are talking about micro services 292 00:17:18,280 --> 00:17:22,079 pretty broadly. But I think if you step one 293 00:17:22,079 --> 00:17:26,720 level down some of the ideas that we talk about, particularly 294 00:17:26,720 --> 00:17:30,440 around fitness functions and how you can use that to assess the 295 00:17:30,440 --> 00:17:34,920 state of your architecture, I think those ideas are getting 296 00:17:34,920 --> 00:17:38,560 more traction. People are looking at what am I 297 00:17:38,560 --> 00:17:43,480 really trying to achieve here and how can I make this concrete 298 00:17:43,560 --> 00:17:46,240 enough that I can actually test for it. 299 00:17:46,840 --> 00:17:49,520 My favorite example, again, for that is maintainable. 300 00:17:49,640 --> 00:17:55,440 You know what does that mean? You and I could disagree on how 301 00:17:55,440 --> 00:17:57,520 maintainable a particular piece of code are. 302 00:17:57,640 --> 00:18:01,520 We couldn't disagree on what the cyclomatic complexity was, 303 00:18:01,520 --> 00:18:05,800 whether or not it followed a particular coding standard or a 304 00:18:05,800 --> 00:18:10,680 naming standard, didn't respect architectural layering rules. 305 00:18:10,880 --> 00:18:15,520 Those things we can measure, but maintainable is in the eye, the 306 00:18:15,520 --> 00:18:17,560 beholder. So I do think we're making 307 00:18:17,560 --> 00:18:23,120 progress in getting people to think more specifically about 308 00:18:23,120 --> 00:18:26,560 what they're trying to achieve and that the mechanism of 309 00:18:26,560 --> 00:18:34,280 fitness functions gives them the ability to say a, here is what 310 00:18:34,280 --> 00:18:36,720 I'm trying to achieve. This is my target architecture, 311 00:18:36,720 --> 00:18:40,120 which is, you know, the theoretical composition of all 312 00:18:40,120 --> 00:18:42,800 of your fitness functions. And this is how I'm doing. 313 00:18:43,760 --> 00:18:47,400 Maybe something in your system load has changed or maybe a new 314 00:18:47,400 --> 00:18:50,200 technology is starting to be used and all of a sudden you 315 00:18:50,200 --> 00:18:54,200 will need to re evaluate some of the architectural choices that 316 00:18:54,200 --> 00:18:56,320 you've made because the situation is now different. 317 00:18:56,960 --> 00:19:01,200 So I think at that level we are starting to make more progress. 318 00:19:01,200 --> 00:19:04,720 You do hear more people talking about fitness functions, but I 319 00:19:04,720 --> 00:19:07,680 would agree with you, it's not it isn't widely adopted. 320 00:19:07,680 --> 00:19:12,000 And I think that also goes back to, you know, it's one thing to 321 00:19:12,000 --> 00:19:15,720 start from a Greenfield and build a completely evolutionary 322 00:19:15,720 --> 00:19:19,240 architecture. It's another thing to take a big 323 00:19:19,240 --> 00:19:22,680 ball of mud and turn it into something that's evolvable. 324 00:19:23,080 --> 00:19:25,280 You've got a long journey ahead of you. 325 00:19:25,280 --> 00:19:28,960 If if you've got lots of balls of mud or I saw this great 326 00:19:28,960 --> 00:19:33,960 graphic on LinkedIn yesterday. There's nothing wrong with 327 00:19:34,400 --> 00:19:40,520 building lasagna, a nice layered monolith, well structured. 328 00:19:41,560 --> 00:19:45,320 You don't want to build a pile of spaghetti, but you don't 329 00:19:45,320 --> 00:19:50,680 necessarily have to start with raviolis either, which I guess 330 00:19:50,680 --> 00:19:52,680 is the metaphor for micro services and that. 331 00:19:52,680 --> 00:19:55,320 But I thought it was a great visual because, you know, it 332 00:19:55,320 --> 00:19:59,400 really gets down to the fact that there is nothing inherently 333 00:19:59,400 --> 00:20:02,440 wrong with a monolith. Yes, there are some things that 334 00:20:02,440 --> 00:20:05,640 you can do with a micro service that you can't do with a 335 00:20:05,640 --> 00:20:10,960 monolith, but then there are problems that you can't have in 336 00:20:10,960 --> 00:20:14,280 a monolith. That you have to deal with in a 337 00:20:14,280 --> 00:20:18,080 micro services architecture. And so I, I think too much of A 338 00:20:18,080 --> 00:20:21,000 focus on let's be as as nimble as possible. 339 00:20:21,000 --> 00:20:23,600 You can end up with a much more complex system than than you 340 00:20:23,600 --> 00:20:26,160 need. And that's why when we talk 341 00:20:26,160 --> 00:20:30,400 about this, we always say you need to start by deciding which 342 00:20:30,400 --> 00:20:32,480 of these things are most most important to you. 343 00:20:32,480 --> 00:20:36,320 And if the volatility isn't 1 of your important entities, don't 344 00:20:36,320 --> 00:20:39,280 worry about it. Yeah, makes sense. 345 00:20:39,320 --> 00:20:41,520 It comes back to what we discussed earlier, right? 346 00:20:41,520 --> 00:20:43,800 It's about what's important to you and pick the right 347 00:20:43,800 --> 00:20:45,600 architecture based on your context, right? 348 00:20:45,960 --> 00:20:48,160 My suspicion is also regarding the tools, right? 349 00:20:48,160 --> 00:20:52,440 Because I don't see many tools focus on solving these kind of 350 00:20:52,440 --> 00:20:54,720 things. But maybe in the future we might 351 00:20:54,720 --> 00:20:56,440 see start seeing these kind of tools. 352 00:20:56,680 --> 00:20:59,000 So maybe let's go to the definition first. 353 00:20:59,000 --> 00:21:01,520 Like I like the your definition for the architecture in the 354 00:21:01,520 --> 00:21:04,760 book, which kind of like defines the three biggest things from 355 00:21:04,760 --> 00:21:06,720 that definition. Fitness function is 1. 356 00:21:06,920 --> 00:21:09,720 So maybe if you can help us, we find first so that the listeners 357 00:21:09,720 --> 00:21:12,480 here can also understand the big picture of evolutionary 358 00:21:12,480 --> 00:21:14,400 architecture. OK. 359 00:21:14,400 --> 00:21:18,320 So there are three things on the evolutionary architecture 360 00:21:18,320 --> 00:21:22,640 supports guided incremental change across multiple 361 00:21:22,640 --> 00:21:28,480 dimensions and fitness functions come in with the guided because 362 00:21:28,760 --> 00:21:33,600 they are your guide, they are your assessment of how close 363 00:21:33,600 --> 00:21:36,680 have you gotten to what it is that you are trying to achieve 364 00:21:37,760 --> 00:21:42,560 incremental, you know we want to be able to make these changes 365 00:21:43,280 --> 00:21:46,640 incrementally as a risk reduction strategy. 366 00:21:46,960 --> 00:21:49,440 And then across multiple dimensions is we need to think 367 00:21:49,440 --> 00:21:52,480 about all of those different alities and we need to think 368 00:21:52,480 --> 00:21:55,280 about all of the different characteristics and how they 369 00:21:55,280 --> 00:21:59,360 interact with each other in determining whether or not we're 370 00:21:59,360 --> 00:22:02,640 being successful. So just to recap, like there's a 371 00:22:02,640 --> 00:22:05,520 guided thing that happens in the evolutionary architecture. 372 00:22:05,520 --> 00:22:07,760 So this is like the fitness function that kind of like 373 00:22:07,760 --> 00:22:10,600 guides you towards a certain fitness as I suppose. 374 00:22:10,960 --> 00:22:13,640 And then incremental change. If you do, if you don't do 375 00:22:13,640 --> 00:22:16,280 incremental change, I think there's very little reason for 376 00:22:16,280 --> 00:22:18,560 you to evolve your architecture simply just like what you 377 00:22:18,560 --> 00:22:20,600 mentioned the example, right, the Jet Propulsion thing. 378 00:22:20,920 --> 00:22:22,920 And the last thing is architecture is involves 379 00:22:22,920 --> 00:22:25,600 multiple dimensions, right? So pick the the most important 380 00:22:25,600 --> 00:22:29,520 dimensions for you and use the fitness function and incremental 381 00:22:29,520 --> 00:22:31,800 change that you do to actually kind of like leave off your 382 00:22:31,800 --> 00:22:34,440 architecture. So maybe let's go to the fitness 383 00:22:34,440 --> 00:22:37,840 function first. I think this is taken from the 384 00:22:37,920 --> 00:22:39,600 theory of evolutionary computing. 385 00:22:40,000 --> 00:22:43,440 And the analogy also is something like the unit test in, 386 00:22:43,440 --> 00:22:45,520 you know, automated test world, right? 387 00:22:45,800 --> 00:22:48,880 So tell us how can we implement this fitness function in, you 388 00:22:48,880 --> 00:22:51,360 know, day-to-day project or kind of like service that we built? 389 00:22:52,200 --> 00:22:56,800 Well, first, some fitness functions act like unit tests, 390 00:22:56,800 --> 00:22:58,960 but some of them are much more system wide. 391 00:22:59,240 --> 00:23:03,320 We come up with basically two different axes to define fitness 392 00:23:03,320 --> 00:23:05,040 functions, static versus dynamic. 393 00:23:05,720 --> 00:23:09,760 Static, obviously it's something that is some kind of analysis. 394 00:23:09,760 --> 00:23:12,440 Maybe you run it in your build, something like cyclomatic 395 00:23:12,440 --> 00:23:15,520 complexity as an example. Dynamic is something that 396 00:23:16,040 --> 00:23:20,480 happens at runtime. So maybe you have some kind of 397 00:23:20,680 --> 00:23:24,520 monitor for CPU utilization. Well, that's a dynamic fitness 398 00:23:24,520 --> 00:23:26,480 function. You don't want your CPU 399 00:23:26,560 --> 00:23:30,280 utilization to get above X. Or maybe it's some kind of 400 00:23:30,280 --> 00:23:34,280 tracer, transaction tracer through a micro services 401 00:23:34,280 --> 00:23:36,120 architecture. Those are dynamic fitness 402 00:23:36,120 --> 00:23:40,240 functions. And then there are fitness 403 00:23:40,240 --> 00:23:43,600 functions that test just one specific thing. 404 00:23:44,160 --> 00:23:46,720 And then there are more holistic fitness functions. 405 00:23:47,160 --> 00:23:53,480 And if you go to the extreme, the Semian army is a dynamic 406 00:23:53,480 --> 00:23:57,440 holistic fitness function or a collection of them actually. 407 00:23:57,760 --> 00:24:01,600 And those happen at runtime. They often look at system wide 408 00:24:01,600 --> 00:24:06,440 characteristics and they're looking at multiple aspects of 409 00:24:06,520 --> 00:24:10,280 of the architecture and how the running system actually behaves 410 00:24:10,600 --> 00:24:12,840 under particular kinds of of stresses. 411 00:24:13,520 --> 00:24:18,920 And so fitness functions should be thought of as a unifying term 412 00:24:18,920 --> 00:24:23,680 for a lot of the different kinds of tests that we've been putting 413 00:24:23,680 --> 00:24:27,240 systems through for a long time. And the advantage of having that 414 00:24:27,240 --> 00:24:31,960 unifying terminology is that you can now talk about security 415 00:24:32,120 --> 00:24:37,240 requirements and operability requirements and performance 416 00:24:37,240 --> 00:24:42,720 requirements as the same thing. How far are we away from what we 417 00:24:42,720 --> 00:24:45,440 said our objective was? What is it going to take to get 418 00:24:45,440 --> 00:24:47,760 there? As opposed to all security 419 00:24:47,760 --> 00:24:50,600 requirements are created equal and must all be implemented 420 00:24:50,600 --> 00:24:53,880 before you can go live? Generally that's not the case. 421 00:24:55,120 --> 00:25:00,320 And so the thing about fitness functions is you want to have it 422 00:25:00,360 --> 00:25:04,360 be automated if possible, but some of them you don't actually 423 00:25:04,360 --> 00:25:07,560 want to automate. But the single most important 424 00:25:07,560 --> 00:25:12,000 characteristic is that you and I will never disagree on whether 425 00:25:12,000 --> 00:25:15,120 it passes or not. It has to be defined in that 426 00:25:15,120 --> 00:25:17,600 way. And that process that you have 427 00:25:17,600 --> 00:25:22,680 to go through to go from maintainable to a suite of 428 00:25:23,000 --> 00:25:28,160 defined functions that represent your definition of maintainable, 429 00:25:28,440 --> 00:25:32,240 that's a difficult exercise, but it's a quite valuable exercise. 430 00:25:33,360 --> 00:25:34,880 Yeah. So speaking about quality 431 00:25:34,880 --> 00:25:36,280 attributes or the ilities, right? 432 00:25:37,440 --> 00:25:39,040 Definitely. It's kind of like vague whenever 433 00:25:39,040 --> 00:25:40,800 we discuss about it. I think you brought a point 434 00:25:40,800 --> 00:25:42,680 about maintainability. What do you mean by 435 00:25:42,680 --> 00:25:44,360 maintainability, right? Everyone has their own 436 00:25:44,360 --> 00:25:47,200 definition and sometimes people focus on certain aspect like 437 00:25:47,200 --> 00:25:50,120 code, maybe maintainability of the service itself or 438 00:25:50,120 --> 00:25:51,880 maintainability of infrastructure, right? 439 00:25:51,880 --> 00:25:53,840 There are so many different maintainability. 440 00:25:53,960 --> 00:25:56,320 So I think the first exercise is to come up with a kind of like a 441 00:25:56,320 --> 00:25:58,360 baseline, right? Everyone needs to understand the 442 00:25:58,360 --> 00:26:00,760 same thing and as much as possible, we should be able to 443 00:26:00,760 --> 00:26:02,680 quantify. Maybe some kind of metrics 444 00:26:03,000 --> 00:26:05,760 doesn't have to be automated, but at least people have the 445 00:26:05,760 --> 00:26:08,600 same understanding, right? Maybe in your experience, having 446 00:26:08,600 --> 00:26:10,760 done this for quite some time, do you think there are some 447 00:26:10,760 --> 00:26:13,920 fitness function that we all software engineering team, 448 00:26:13,920 --> 00:26:16,200 right, must have within our system? 449 00:26:16,280 --> 00:26:19,760 I know that it's hard because we mentioned that your importance 450 00:26:19,760 --> 00:26:21,720 of certain characteristics is different, right? 451 00:26:21,760 --> 00:26:24,280 But maybe there are some basic one that you think are the most 452 00:26:24,280 --> 00:26:29,280 important for everyone to adopt. Well, assuming you decide that 453 00:26:29,280 --> 00:26:32,880 you want your system to be evolvable, to me, one of the 454 00:26:32,880 --> 00:26:38,040 most universal requirements is you have to be able to 455 00:26:38,040 --> 00:26:41,120 understand what the code is doing and what the system is 456 00:26:41,120 --> 00:26:44,200 doing because you can't change something you don't understand. 457 00:26:44,720 --> 00:26:50,200 And so the closest I've got to a universal with the caveat, yes, 458 00:26:50,200 --> 00:26:53,520 I know I'm a, you know, I'm one of those, you know, scientists, 459 00:26:53,520 --> 00:26:56,280 I need to be precise with the caveat, you've decided 460 00:26:56,280 --> 00:27:01,480 evolvability is important. You want to have guardrails in 461 00:27:01,480 --> 00:27:05,840 there for code quality. Do you have good separation? 462 00:27:05,840 --> 00:27:09,160 Do you have low cyclomatic complexity? 463 00:27:09,480 --> 00:27:13,200 That's probably the closest to a universal that that you're going 464 00:27:13,200 --> 00:27:15,840 to get. But we've actually seen quite a 465 00:27:15,840 --> 00:27:21,440 bit of creativity where people are trying to solve for a 466 00:27:21,440 --> 00:27:24,320 particular problem. One of my favorite fitness 467 00:27:24,320 --> 00:27:28,920 functions that that we heard about is we had a client and 468 00:27:29,200 --> 00:27:32,920 their legal department had come to the the delivery team and 469 00:27:32,920 --> 00:27:35,760 said, now we're using all these open source frameworks and 470 00:27:35,760 --> 00:27:38,400 they're going to notify us if they change their license, 471 00:27:38,440 --> 00:27:40,960 right? And, you know, the team just 472 00:27:40,960 --> 00:27:44,320 laughed as you are right now because of course they're not 473 00:27:44,320 --> 00:27:46,920 going to notify everybody. They have no idea who's using 474 00:27:46,920 --> 00:27:49,560 this. And the lawyer got all worried 475 00:27:49,560 --> 00:27:52,440 about that because, oh, well, we could inadvertently be using 476 00:27:52,440 --> 00:27:54,640 something that has a license and I haven't approved. 477 00:27:55,240 --> 00:27:57,880 And so they started to, you know, come up with all of these 478 00:27:57,880 --> 00:28:01,440 natural language processing ideas for, you know, and then 479 00:28:01,440 --> 00:28:05,600 somebody came up with this very simple, elegant solution. 480 00:28:06,720 --> 00:28:12,800 Hatch all of the license files, put in a unit test that hashes 481 00:28:12,800 --> 00:28:16,920 the current license file and compares the hash to what's in 482 00:28:16,920 --> 00:28:19,560 the test. And if it's different, you send 483 00:28:19,560 --> 00:28:22,640 an e-mail to the lawyer with a link to the new file. 484 00:28:23,520 --> 00:28:26,720 And then the lawyer can check, you know, and, and it's, it was, 485 00:28:26,880 --> 00:28:29,120 it's brilliant in its simplicity. 486 00:28:29,800 --> 00:28:32,960 And then as soon as the lawyer signs off, they do the rehash, 487 00:28:32,960 --> 00:28:36,760 they put it back into the build and now they go merrily along. 488 00:28:37,120 --> 00:28:40,720 And so the system is notifying the lawyer when the license file 489 00:28:40,720 --> 00:28:44,120 changes. And it was a brilliant solution. 490 00:28:44,120 --> 00:28:47,560 You didn't need to do anything fancy to say, OK, did the 491 00:28:47,560 --> 00:28:50,240 semantics of this. Well, how's the team going to 492 00:28:50,240 --> 00:28:53,120 maintain that? All they need to know is that 493 00:28:53,120 --> 00:28:57,120 it's changed. So I think as people get more 494 00:28:57,120 --> 00:29:02,480 used to using fitness functions, we'll start to see more ideas on 495 00:29:02,840 --> 00:29:07,480 well, here's some fitness functions around X, here's some 496 00:29:07,480 --> 00:29:10,920 fitness functions around Y. In much the same way that many 497 00:29:10,920 --> 00:29:14,240 people will use variants of the Semian Army, we're going to have 498 00:29:14,240 --> 00:29:17,080 similar kinds of things, I think, happening across 499 00:29:17,400 --> 00:29:19,720 architectural patterns, things of that nature. 500 00:29:20,760 --> 00:29:23,800 Yeah, I hope to see a lot more patterns or recipe book, you 501 00:29:23,800 --> 00:29:26,560 know, out there that people use in terms of fitness functions. 502 00:29:26,560 --> 00:29:30,040 So for us to get inspiration or maybe the tools also that we can 503 00:29:30,040 --> 00:29:32,760 just, you know, use in a open source fashion, right. 504 00:29:33,240 --> 00:29:35,840 So I think another thing that is very fundamentals in the 505 00:29:35,880 --> 00:29:37,880 evolutionary architecture implementation, right? 506 00:29:37,880 --> 00:29:40,720 There are two aspects which is kind of like the governance 507 00:29:40,720 --> 00:29:43,680 aspect and the other one is the engineering practice aspect. 508 00:29:43,880 --> 00:29:46,600 Maybe if we can cover each right, because I find those two 509 00:29:46,600 --> 00:29:48,280 are really important because they are kind of like a 510 00:29:48,280 --> 00:29:52,000 collection of multiple different principles, paradigm, 511 00:29:52,000 --> 00:29:55,560 philosophies that I think we all need to get reminded of. 512 00:29:55,800 --> 00:29:58,200 So maybe let's start with the governance aspect. 513 00:29:58,600 --> 00:30:02,440 Well, I, I think so often governance is this dirty word 514 00:30:02,840 --> 00:30:05,720 because you've got these architects sitting on high, 515 00:30:05,720 --> 00:30:10,080 looking down upon the the minions doing all of the work, 516 00:30:10,080 --> 00:30:12,600 and they're going to say, no, you can't. 517 00:30:13,160 --> 00:30:16,800 Yeah, governance. When you get to any kind of 518 00:30:16,800 --> 00:30:21,480 scale, you have no choice. You have to have some level of 519 00:30:21,520 --> 00:30:24,120 governance. Now an engineering leader can 520 00:30:24,120 --> 00:30:27,800 decide what level. I know of one CTO that was 521 00:30:27,800 --> 00:30:31,440 trying to break a pattern of excessive reuse. 522 00:30:31,640 --> 00:30:36,760 And so he said No2 micro services can be written on the 523 00:30:36,760 --> 00:30:40,240 same technology stack and language and so it makes it 524 00:30:40,480 --> 00:30:42,680 impossible to really reuse anything. 525 00:30:43,160 --> 00:30:46,480 I thought that was a bit extreme, but he was trying to 526 00:30:46,480 --> 00:30:49,560 make an organizational change and sometimes the pendulum has 527 00:30:49,600 --> 00:30:52,880 to swing like that. So what are the principles of 528 00:30:52,920 --> 00:30:55,080 evolutionary architecture that you can share with us? 529 00:30:55,640 --> 00:30:59,480 The value though, of fitness functions for governance is 530 00:30:59,480 --> 00:31:02,360 enormous because anything that's in a fitness function, 531 00:31:02,360 --> 00:31:05,680 particularly an automated fitness function, you never have 532 00:31:05,680 --> 00:31:07,680 to do any kind of architectural review. 533 00:31:08,680 --> 00:31:11,840 No, you're, you have no cyclic dependencies because you've got 534 00:31:11,840 --> 00:31:14,800 a test in there that will fail the build if anybody 535 00:31:14,800 --> 00:31:17,000 inadvertently adds a cyclic dependency. 536 00:31:17,640 --> 00:31:21,120 And so all of those concerns go away from a governance 537 00:31:21,120 --> 00:31:23,200 perspective. And you can focus your 538 00:31:23,200 --> 00:31:28,640 governance discussions then on those places where you've got 539 00:31:28,640 --> 00:31:31,320 two things and you've got to make a trade off and you don't 540 00:31:31,320 --> 00:31:32,720 really know how to make that work. 541 00:31:32,720 --> 00:31:36,600 And so you can put the brain power of the humans in the 542 00:31:36,600 --> 00:31:40,360 places where you need that creativity and you can leave the 543 00:31:40,360 --> 00:31:42,880 road stuff. One of the, I think it's the 544 00:31:42,880 --> 00:31:46,080 doctor monkey in the in the semi and army checks to make sure all 545 00:31:46,080 --> 00:31:48,360 Restful endpoints are properly configured. 546 00:31:49,120 --> 00:31:53,080 So you never have to worry about it because it'll get tossed out 547 00:31:53,400 --> 00:31:57,840 if it's not properly configured. So the shift of the governance 548 00:31:58,440 --> 00:32:01,320 that we're talking about from the perspective of evolutionary 549 00:32:01,320 --> 00:32:07,000 architecture really comes down to focusing on the outcomes, not 550 00:32:07,000 --> 00:32:10,120 the implementations. What are the outcomes we are 551 00:32:10,120 --> 00:32:12,400 trying to achieve? What are the behaviors we want 552 00:32:12,400 --> 00:32:15,960 the system to exhibit? Not how you're going to get 553 00:32:15,960 --> 00:32:18,400 there. And that allows the delivery 554 00:32:18,400 --> 00:32:24,400 teams to work within the sandbox that the governance organization 555 00:32:24,400 --> 00:32:29,880 has put into place, but then be creative about how they might 556 00:32:30,280 --> 00:32:34,200 actually implement something to achieve that behavior. 557 00:32:34,200 --> 00:32:39,360 And you can also then have a basis of a conversation that 558 00:32:39,360 --> 00:32:45,400 says, I know our standard tool for this is X, but we're trying 559 00:32:45,400 --> 00:32:50,600 to achieve the outcome. And in our situation, because of 560 00:32:51,080 --> 00:32:56,520 PQ and RY works better to achieve the outcome and you can 561 00:32:56,520 --> 00:32:59,840 have those discussions. And so the discussions become 562 00:33:00,160 --> 00:33:04,360 less about, no, you can't use that because I told you, you had 563 00:33:04,360 --> 00:33:07,600 to use something else. But this is how we're going to 564 00:33:07,920 --> 00:33:11,040 go about achieving the outcome. And This is why we think this is 565 00:33:11,040 --> 00:33:13,280 a better way to achieve the outcome. 566 00:33:13,880 --> 00:33:18,280 And so that's one of those kind of underlying philosophies is 567 00:33:18,640 --> 00:33:22,000 let's be focused on outcomes, not implementations. 568 00:33:22,720 --> 00:33:28,000 Another aspect that is important here is it has to do with how 569 00:33:28,000 --> 00:33:32,800 you architect your system. And Domain Driven Design has 570 00:33:32,840 --> 00:33:36,160 really helped us here because it's given us this language and 571 00:33:36,160 --> 00:33:42,240 this idea of a bounded context that makes sense within the 572 00:33:42,240 --> 00:33:46,560 business domain. Because if you think about a 573 00:33:46,560 --> 00:33:50,080 system in terms of its implementation, you're going to 574 00:33:50,080 --> 00:33:53,040 talk about SAP or you're going to talk about Salesforce, or 575 00:33:53,040 --> 00:33:56,320 you're going to talk about, you know, the customer ordering 576 00:33:56,320 --> 00:33:59,360 system. The people who are refining 577 00:33:59,360 --> 00:34:03,320 business processes and creating new business processes, they 578 00:34:03,320 --> 00:34:07,760 don't care if something is stored in Salesforce, ACRM or a 579 00:34:07,760 --> 00:34:12,719 shipping system. They think about the customer, 580 00:34:12,880 --> 00:34:16,000 they think about the product, and they think about, you know, 581 00:34:16,000 --> 00:34:22,040 the logistics flow. The more our systems have their 582 00:34:22,040 --> 00:34:28,679 boundaries drawn around aspects of functionality that correspond 583 00:34:28,920 --> 00:34:32,679 to what the people who are creating the business process 584 00:34:32,679 --> 00:34:36,440 have as their chunks, they're going to design the business 585 00:34:36,440 --> 00:34:38,480 process by rearranging their chunks. 586 00:34:39,239 --> 00:34:44,440 We can much more readily implement that process if our 587 00:34:44,440 --> 00:34:47,800 chunks have the same ability to move around. 588 00:34:48,400 --> 00:34:52,719 And I actually think that's where microservices have been 589 00:34:52,719 --> 00:34:58,320 successful, where SOA version 1 failed so miserably is the 590 00:34:58,320 --> 00:35:00,840 boundary. So often in that early 591 00:35:01,000 --> 00:35:04,440 implementation of SOA were all around systems. 592 00:35:04,560 --> 00:35:08,760 OK, we are going to create exposed services for SAP. 593 00:35:10,000 --> 00:35:15,160 Why? You know, and so I of all of the 594 00:35:15,600 --> 00:35:19,080 principles and you know, there's several others, I think those 595 00:35:19,080 --> 00:35:23,000 are the the most important ones underlying evolutionary 596 00:35:23,000 --> 00:35:25,120 architecture. Right. 597 00:35:25,480 --> 00:35:26,800 I think it's really insightful, right? 598 00:35:26,800 --> 00:35:29,920 First, it's like focus on the outcome, not the actual how 599 00:35:29,920 --> 00:35:32,800 implementation, right? And I think DDD is kind of like 600 00:35:32,800 --> 00:35:36,600 the fundamentals of, you know, coming up a software that is 601 00:35:36,600 --> 00:35:37,920 aligned with the business, right? 602 00:35:38,120 --> 00:35:41,080 And the other thing that is commonly also mentioned when we 603 00:35:41,080 --> 00:35:43,840 talk about bounded context, you know, micro service and all that 604 00:35:43,840 --> 00:35:47,400 is about Conway's Law. I think you have Conway's Law 605 00:35:47,400 --> 00:35:50,360 and Postel's Law as part of this evolutionary architecture as 606 00:35:50,360 --> 00:35:52,240 well. Maybe explain us why these two 607 00:35:52,240 --> 00:35:54,560 laws are important in evolutionary architecture. 608 00:35:55,520 --> 00:35:58,480 Well, we'll, we'll, we'll start with Pastel's law. 609 00:35:59,840 --> 00:36:05,720 Simply put, Pastel's law says be generous in what you receive and 610 00:36:05,720 --> 00:36:11,400 stingy in what you produce. And so the, the standard example 611 00:36:11,400 --> 00:36:17,240 I, I use, if you are receiving address information and all you 612 00:36:17,240 --> 00:36:21,800 need is the zip code, post code, some kind of Geo locator, don't 613 00:36:21,800 --> 00:36:24,640 validate the whole address. You don't need to. 614 00:36:25,360 --> 00:36:28,200 And that way if somebody decides, oh, I need to add an 615 00:36:28,200 --> 00:36:32,680 address line to, to this thing, you won't break. 616 00:36:32,680 --> 00:36:34,600 Now, of course, you've got the great big asterisk. 617 00:36:34,600 --> 00:36:38,480 Don't open up a security hole. But the point is focus on the 618 00:36:38,480 --> 00:36:43,320 information that you really need, because that way your 619 00:36:43,320 --> 00:36:47,680 system will only require change if it actually has to change. 620 00:36:48,360 --> 00:36:52,040 There's no way that we can prevent any breaking change from 621 00:36:52,040 --> 00:36:56,200 ever happening, but we want to limit it to where it really has 622 00:36:56,200 --> 00:37:00,080 to break because we are trying to do something fundamentally 623 00:37:00,080 --> 00:37:03,040 different. But you want to be very stingy 624 00:37:03,040 --> 00:37:07,440 in what you expose because again, you have no idea who's 625 00:37:07,440 --> 00:37:09,560 actually using what you put out there. 626 00:37:10,200 --> 00:37:14,000 What One of the sadder examples I saw of this, we had one client 627 00:37:14,000 --> 00:37:17,040 who did everything right in their package selection. 628 00:37:17,560 --> 00:37:21,240 They said we're going to change all of our business processes to 629 00:37:21,240 --> 00:37:25,160 do what the package wants. And that way we don't have all 630 00:37:25,160 --> 00:37:28,880 of these customizations and, and so we can upgrade whenever we 631 00:37:28,880 --> 00:37:32,920 we, we get a new version. Wonderful idea. 632 00:37:33,880 --> 00:37:37,120 But what they didn't do was keep track of who was actually 633 00:37:37,400 --> 00:37:39,640 connecting directly to the database. 634 00:37:39,640 --> 00:37:44,800 And they had 87 reports that were completely tied to the 635 00:37:44,800 --> 00:37:47,840 database schema. And so they had to rewrite all 636 00:37:47,840 --> 00:37:49,920 of those reports before they could upgrade. 637 00:37:50,400 --> 00:37:55,000 And they hadn't realized that because people just said, oh, 638 00:37:55,000 --> 00:37:58,480 well, you know, I'll just hit the database for that report. 639 00:37:58,920 --> 00:38:02,880 And so even when you don't intend for somebody to use it, 640 00:38:03,440 --> 00:38:06,640 people still are going to use it if they can. 641 00:38:06,800 --> 00:38:11,440 And you've made a contract, even though you're in a contract that 642 00:38:11,440 --> 00:38:14,360 you don't know you're in. And so that's Pastel's law, 643 00:38:14,720 --> 00:38:19,560 Conway's Law. People try to fight Conway's Law 644 00:38:20,280 --> 00:38:25,960 and you just can't do it. Conway's Law, my version is a 645 00:38:26,000 --> 00:38:29,080 system will reflect the communication dysfunction of the 646 00:38:29,080 --> 00:38:33,480 organization that builds it. If the people don't talk 647 00:38:33,480 --> 00:38:36,720 effectively to each other, the systems that they're responsible 648 00:38:36,720 --> 00:38:39,720 for or not going to talk to each other. 649 00:38:39,720 --> 00:38:42,440 And, you know, I would sometimes look very clever because I would 650 00:38:42,440 --> 00:38:45,040 come in and have lunch with the architectural and then go in and 651 00:38:45,040 --> 00:38:49,440 talk to the VP and say, OK, the integration between these two 652 00:38:49,440 --> 00:38:52,200 systems is broken. How in the world do you know 653 00:38:52,200 --> 00:38:54,320 that you haven't looked at a piece of code? 654 00:38:55,360 --> 00:38:59,000 They said, yeah, but I, I, I saw the tech leads in the lunchroom 655 00:38:59,000 --> 00:39:04,120 and they walked that states are like, you know, and so you can 656 00:39:04,120 --> 00:39:07,440 use Conway's law to your advantage in when you look at 657 00:39:07,440 --> 00:39:11,920 what is, what do I really want my architecture to reflect and 658 00:39:11,920 --> 00:39:15,320 then reorganize your teams and they're going to produce it. 659 00:39:15,320 --> 00:39:18,400 It's just going to happen. We call it the inverse Conway 660 00:39:18,880 --> 00:39:21,280 maneuver. Yeah. 661 00:39:21,600 --> 00:39:24,440 So I think Conway's law is always kind of like brought up 662 00:39:24,640 --> 00:39:26,520 in so many various discussions, right? 663 00:39:26,520 --> 00:39:29,160 I think for listeners who are not yet familiar with these two 664 00:39:29,160 --> 00:39:32,040 laws, right, make sure you research more because they are 665 00:39:32,200 --> 00:39:35,480 fundamentals, even though they are like around for so many, 666 00:39:35,480 --> 00:39:37,600 many years, right? People try to kind of like beat 667 00:39:37,600 --> 00:39:39,560 them, but eventually they couldn't. 668 00:39:40,000 --> 00:39:42,560 So those are kind of like the governance and principles 669 00:39:42,560 --> 00:39:44,480 aspect. What are some of the engineering 670 00:39:44,480 --> 00:39:47,160 practices that you think software engineering teams have 671 00:39:47,160 --> 00:39:52,960 to adopt and practice? Well, First off, I think an 672 00:39:52,960 --> 00:39:59,960 underlying prerequisite is the discipline, the infrastructural 673 00:39:59,960 --> 00:40:02,640 discipline and the deployment discipline that comes from 674 00:40:02,640 --> 00:40:05,920 continuous delivery. You don't have to go all the way 675 00:40:05,920 --> 00:40:09,040 to continuous deployment, although there's, there's a new 676 00:40:09,040 --> 00:40:13,280 book out that makes a very strong case for why you should 677 00:40:13,280 --> 00:40:16,600 try to get there. But you at least need to know 678 00:40:17,240 --> 00:40:20,360 that your deployments are going to run smoothly. 679 00:40:20,360 --> 00:40:23,640 And so the risk mitigation aspects of continuous delivery 680 00:40:23,640 --> 00:40:27,800 are important when you're talking about the kinds of. 681 00:40:28,360 --> 00:40:33,800 Dramatic changes, you need to know what you're deploying into 682 00:40:34,120 --> 00:40:38,800 and so that you can more readily debug anything that that that's 683 00:40:38,800 --> 00:40:41,320 happening. So I think that's the first. 684 00:40:41,880 --> 00:40:47,960 The second is this whole idea of evolutionary database design and 685 00:40:47,960 --> 00:40:52,560 database refactoring. I've been in many conversations 686 00:40:52,680 --> 00:40:57,080 over the years with, you know, people who would say, OK, well, 687 00:40:57,880 --> 00:41:02,080 Agilent incremental, that's fine for developers, but I need to 688 00:41:02,080 --> 00:41:06,120 have a holistic vision of my complete user experience or no, 689 00:41:06,120 --> 00:41:09,200 I can't test the system until it's done because you're going 690 00:41:09,200 --> 00:41:11,320 to be changing it and then I'm going to have to retest it and 691 00:41:11,560 --> 00:41:15,480 all of those things. The team that I think has always 692 00:41:15,480 --> 00:41:20,440 had the strongest argument for, no, it can't be incremental were 693 00:41:20,440 --> 00:41:23,920 the Dbas because data migration is hard. 694 00:41:24,520 --> 00:41:28,600 It sounds so simple. Copy it from here to here. 695 00:41:29,120 --> 00:41:33,480 No, but it's it's hard. And so there's an entire book 696 00:41:33,480 --> 00:41:37,240 called Refactoring Databases. One of our co-authors in the 697 00:41:37,240 --> 00:41:40,800 second edition, Pramod Siddagi is one of the authors of that. 698 00:41:41,240 --> 00:41:45,400 So that that is another critical engineering practice. 699 00:41:45,960 --> 00:41:51,880 I also like to talk about contract testing because again, 700 00:41:51,880 --> 00:41:54,120 one of the things that you were trying to do with an 701 00:41:54,120 --> 00:41:57,040 evolutionary architecture is to make it as easy to change things 702 00:41:57,040 --> 00:42:01,920 as possible. And so if I understand the 703 00:42:01,920 --> 00:42:05,560 assumptions that you're making of my system and you understand 704 00:42:05,560 --> 00:42:09,560 the assumptions that I am making of yours, you know, so we both 705 00:42:09,560 --> 00:42:12,680 know what's happening. And then we've got the same with 706 00:42:12,680 --> 00:42:15,800 Neil. And then we can make whatever 707 00:42:15,800 --> 00:42:20,880 changes that we want, paying absolutely no attention to each 708 00:42:20,880 --> 00:42:23,440 other until one of those tests break. 709 00:42:24,000 --> 00:42:27,240 And let's say my test with Neil breaks. 710 00:42:27,760 --> 00:42:31,040 So I have a conversation with Neil because I'm trying to 711 00:42:31,040 --> 00:42:34,080 implement something that violates something that he's 712 00:42:34,080 --> 00:42:36,960 expecting of me. And so we negotiate what change 713 00:42:36,960 --> 00:42:39,520 has to happen. We're continuing to ignore you 714 00:42:40,520 --> 00:42:41,960 because none of your tests are broken. 715 00:42:41,960 --> 00:42:45,040 And as long as your tests don't break, we can continue to ignore 716 00:42:45,040 --> 00:42:46,720 you. And then we get all the tests 717 00:42:46,720 --> 00:42:49,720 working again, and then we go back to ignoring everybody. 718 00:42:50,440 --> 00:42:54,160 It maximizes the amount of independent work that can take 719 00:42:54,160 --> 00:42:57,840 place, and it helps us understand what those boundaries 720 00:42:57,840 --> 00:43:02,440 are and why. And that is a critical piece to 721 00:43:02,440 --> 00:43:04,320 being able to evolve in architecture. 722 00:43:04,320 --> 00:43:09,280 Because if I don't know what you're expecting of me, I can 723 00:43:09,280 --> 00:43:12,280 inadvertently break you. And we don't want that. 724 00:43:12,560 --> 00:43:16,080 And so that's another important technique. 725 00:43:16,560 --> 00:43:21,640 And then you start to get into things that aren't necessarily 726 00:43:21,640 --> 00:43:24,120 as fundamental. I believe those things are 727 00:43:24,120 --> 00:43:27,920 fundamental and you have to have the right kind of testing safety 728 00:43:27,920 --> 00:43:29,960 net. And one of the things that we 729 00:43:29,960 --> 00:43:33,280 found is if you think properly about testing, you're actually 730 00:43:33,280 --> 00:43:36,480 going to end up with a cleaner architecture because you have to 731 00:43:36,480 --> 00:43:40,040 have good boundaries to be able to properly test things. 732 00:43:40,840 --> 00:43:44,480 But then we often, for example, talk about choreography over 733 00:43:44,680 --> 00:43:48,200 orchestration. And this is where you really 734 00:43:48,200 --> 00:43:50,560 start to get into the these trade off discussions. 735 00:43:50,560 --> 00:43:54,040 Much like should I go with a well structured monolith or 736 00:43:54,040 --> 00:43:58,360 should I go to micro services? You have much more flexibility 737 00:43:58,360 --> 00:44:01,720 with micro services than you do with a well structured monolith. 738 00:44:02,320 --> 00:44:07,280 Emphasis on the well structured. This is not spaghetti monoliths. 739 00:44:07,280 --> 00:44:11,600 This is nice, nice structured lasagna monoliths. 740 00:44:12,240 --> 00:44:17,080 And if you don't need that level of flexibility, it's not worth 741 00:44:17,080 --> 00:44:20,320 paying for the complexity. But sometimes you do. 742 00:44:20,840 --> 00:44:23,040 And it's the same with choreography versus 743 00:44:23,040 --> 00:44:25,560 orchestration. If you've got an orchestrator, 744 00:44:25,560 --> 00:44:28,560 that orchestrator is going to solve some of those problems 745 00:44:28,880 --> 00:44:31,880 that you have of these independent actors, but you're 746 00:44:31,880 --> 00:44:37,160 introducing coupling that is not strictly necessary. 747 00:44:38,000 --> 00:44:41,560 But there are all kinds of errors that you have to take 748 00:44:41,560 --> 00:44:44,160 care of yourself in a choreographed system. 749 00:44:44,720 --> 00:44:47,840 And so again, if you need that flexibility, take it. 750 00:44:48,440 --> 00:44:51,720 But if you don't need the flexibility, then go with 751 00:44:51,720 --> 00:44:56,000 something that that's simpler. Right, thanks for highlighting 752 00:44:56,000 --> 00:44:58,840 all these important practices. I think continuous delivery is 753 00:44:58,840 --> 00:45:01,240 something that is a must, right? Especially when you want to do 754 00:45:01,240 --> 00:45:03,800 incremental change, because without continuous delivery, 755 00:45:03,960 --> 00:45:06,080 there's just no way for you to do incremental change. 756 00:45:06,480 --> 00:45:09,640 And the other one is like the contract testing, especially in 757 00:45:09,640 --> 00:45:12,280 the micro service world, right, where you integrate with so many 758 00:45:12,280 --> 00:45:14,680 different third parties and services, you know, knowing 759 00:45:14,680 --> 00:45:16,560 where you break or when you break. 760 00:45:16,800 --> 00:45:18,160 I think it's very important as well. 761 00:45:18,560 --> 00:45:20,280 You talk about evolutionary database design. 762 00:45:20,720 --> 00:45:23,480 I don't know whether this has been a common thing, but I think 763 00:45:23,480 --> 00:45:25,880 many, many language and framework kind of like covers 764 00:45:25,880 --> 00:45:29,400 this aspect of evolutionary at least RDBMS, kind of like 765 00:45:29,400 --> 00:45:31,920 database migration. And the last one is about 766 00:45:31,920 --> 00:45:33,760 choreography. I think it touches a little bit 767 00:45:33,760 --> 00:45:36,400 about event driven architecture where you kind of like have 768 00:45:36,640 --> 00:45:38,800 choreography rather than orchestration. 769 00:45:39,560 --> 00:45:42,640 So thanks for sharing all this. So definitely one aspect that is 770 00:45:42,640 --> 00:45:46,200 kind of like trendy these days is about introduction of AILLM, 771 00:45:46,200 --> 00:45:48,160 generative AI and all those stuff, right? 772 00:45:48,480 --> 00:45:51,760 So what is your take about the invasion of AI and with 773 00:45:51,840 --> 00:45:54,840 evolutionary architecture? Because one good aspect about AI 774 00:45:54,840 --> 00:45:59,400 is that they can create tests. And these days people also use a 775 00:45:59,520 --> 00:46:02,520 lot of suggestions from AI assistant to actually generate 776 00:46:02,520 --> 00:46:04,280 code. Is this something that 777 00:46:04,280 --> 00:46:07,440 evolutionary architecture needs to kind of like govern as well? 778 00:46:07,440 --> 00:46:11,000 What's your take about AI? Well, that's one of the things 779 00:46:11,000 --> 00:46:14,120 that that Neil and I've been talking about for a while. 780 00:46:14,760 --> 00:46:19,880 We can use fitness functions at at least to you know, 781 00:46:20,040 --> 00:46:23,400 particularly the those the suite of code quality fitness 782 00:46:23,400 --> 00:46:28,680 functions that have brought up. We can use that to assess the 783 00:46:29,280 --> 00:46:33,760 generated code, you know, and there's still anecdotal 784 00:46:33,760 --> 00:46:38,640 evidence, I wouldn't call it solid evidence yet that these 785 00:46:38,640 --> 00:46:45,480 code generators, they will tend to copy paste and modify as 786 00:46:45,480 --> 00:46:50,560 opposed to trying to abstract. And so running a simple copy 787 00:46:50,560 --> 00:46:54,560 paste detector can help you see if your code base is starting to 788 00:46:54,920 --> 00:47:00,680 get out of control in that way. I've been interested and 789 00:47:00,680 --> 00:47:04,200 involved in AI for most of my career. 790 00:47:04,680 --> 00:47:09,000 And so I've seen, you know, the AI winters, there's certainly a 791 00:47:09,000 --> 00:47:14,480 lot of hype going on right now, but these models are 792 00:47:15,200 --> 00:47:19,400 qualitatively more powerful than any models that we've had in in 793 00:47:19,400 --> 00:47:24,560 the past. And so I do think that we have 794 00:47:24,560 --> 00:47:30,200 the potential to use these LLM based systems, particularly the 795 00:47:30,200 --> 00:47:33,960 the more coding focused ones to help us in development. 796 00:47:34,480 --> 00:47:36,960 One of the things that that Thaworks has has been 797 00:47:36,960 --> 00:47:43,680 experimenting with as an example, is using these LLMS on 798 00:47:43,680 --> 00:47:47,400 a legacy code base to help understand how the information 799 00:47:47,400 --> 00:47:52,840 actually flows through that legacy code base and to help use 800 00:47:52,840 --> 00:47:57,960 that information to start to refactor and ultimately replace 801 00:47:58,240 --> 00:48:01,360 a legacy code base. It's still early days, but what 802 00:48:01,360 --> 00:48:07,000 we're seeing is really a fundamental increase in the 803 00:48:07,280 --> 00:48:12,040 ability of a human to understand a code base. 804 00:48:12,120 --> 00:48:16,240 And it's because the human is relying on information and the 805 00:48:16,240 --> 00:48:19,120 LLM in the background is doing a lot of hard work. 806 00:48:19,640 --> 00:48:21,720 So I think we're going to see more of that. 807 00:48:21,800 --> 00:48:25,000 As I said earlier, you cannot evolve the system, you can't 808 00:48:25,000 --> 00:48:27,240 understand. And that's one of the problems 809 00:48:27,240 --> 00:48:30,240 with many of these old legacy systems is people just don't 810 00:48:30,240 --> 00:48:31,720 understand how they work anymore. 811 00:48:32,040 --> 00:48:37,560 And so the more we can build tools to help understand these 812 00:48:37,560 --> 00:48:41,080 legacy systems, that puts us in a much better position to 813 00:48:41,080 --> 00:48:44,200 actually be able to modify those systems. 814 00:48:44,880 --> 00:48:46,640 Right. You mentioned something that is 815 00:48:46,640 --> 00:48:48,600 I think quite insightful for me, right. 816 00:48:48,600 --> 00:48:51,920 So you mentioned that code generation is typically kind of 817 00:48:51,920 --> 00:48:54,560 like copy paste modifying, evolving a little bit here and 818 00:48:54,560 --> 00:48:56,960 there, right? But it's pretty rare to see AI 819 00:48:57,080 --> 00:49:00,200 who can suggest you some abstractions or kind of like a 820 00:49:00,200 --> 00:49:02,760 domain driven kind of suggestion as well. 821 00:49:03,240 --> 00:49:06,360 Is this something that every developers have to be concerned 822 00:49:06,360 --> 00:49:09,640 with or kind of like the gotcha that we all need to be aware of? 823 00:49:09,640 --> 00:49:12,680 Because most of the time now everyone integrates their 824 00:49:12,680 --> 00:49:15,920 copilot and suddenly, you know, you see a lot of code being 825 00:49:15,920 --> 00:49:18,040 suggested and they just accept, accept, accept. 826 00:49:18,320 --> 00:49:21,520 I think there's also a lot of studies saying that code churn 827 00:49:21,520 --> 00:49:24,600 is really high these days and a lot more codes are being 828 00:49:24,600 --> 00:49:27,000 generated maybe in terms of lines of code, right? 829 00:49:27,000 --> 00:49:29,640 Grows really fast simply because, yeah, we just accept 830 00:49:29,640 --> 00:49:32,200 rather than think through, you know, what kind of solution that 831 00:49:32,320 --> 00:49:34,680 AI is suggesting. So what is your view about 832 00:49:34,680 --> 00:49:37,840 these, especially in terms of fitness function or 833 00:49:37,840 --> 00:49:41,320 architectural aspect that maybe one day is going to be like 834 00:49:41,320 --> 00:49:43,960 another big bowl of mark generated by AI, which is kind 835 00:49:43,960 --> 00:49:47,920 of like? Even worse, yeah, that is one of 836 00:49:47,920 --> 00:49:52,880 the things I worry about is that we basically increased the 837 00:49:52,960 --> 00:49:57,880 productive capacity of our industry to create that code and 838 00:49:57,880 --> 00:50:02,280 that doesn't help anybody. As I said, I do think we can use 839 00:50:02,400 --> 00:50:06,400 fitness functions to at least monitor what's happening with 840 00:50:06,440 --> 00:50:09,920 the code base. One of the things that I worry 841 00:50:09,920 --> 00:50:15,040 about though is in many ways our industry is kind of an 842 00:50:15,040 --> 00:50:19,680 apprentice model where you have junior developers who are 843 00:50:19,680 --> 00:50:23,600 learning from more experienced developers and it goes on. 844 00:50:24,360 --> 00:50:30,240 Unless these coding assistants get much better pretty quickly, 845 00:50:30,520 --> 00:50:34,960 I would worry about in 20 years time, where are our star 846 00:50:34,960 --> 00:50:38,640 developers going to have come from The notion that somebody is 847 00:50:38,640 --> 00:50:42,240 going to learn how to code from a coding assistant. 848 00:50:42,640 --> 00:50:46,040 We're not there yet. They're too likely to put out 849 00:50:46,040 --> 00:50:49,000 things that are wrong. There was one study we actually 850 00:50:49,000 --> 00:50:53,680 did a podcast on this that was done by the code scene people 851 00:50:54,280 --> 00:50:57,320 when the coding assistant that they were working with and they 852 00:50:57,560 --> 00:51:01,400 they went across as a suite of models, recommended a 853 00:51:01,400 --> 00:51:04,400 refactoring. In the best case, they were 854 00:51:04,400 --> 00:51:11,080 right 37% of the time. So in over 60%, the refactoring 855 00:51:11,080 --> 00:51:16,240 that they suggested did not maintain the correct behavior of 856 00:51:16,240 --> 00:51:19,880 the code. If you as a developer got things 857 00:51:19,880 --> 00:51:22,920 wrong 2/3 of the time, you're not going to keep your job for 858 00:51:22,920 --> 00:51:26,720 very long. As a professor, if 2/3 of the 859 00:51:26,720 --> 00:51:31,040 stuff that I said was wrong, I am not doing a service to my 860 00:51:31,040 --> 00:51:32,880 students. They're not going to be able to 861 00:51:32,880 --> 00:51:37,200 learn if they have to figure out which 2/3 of the stuff that I've 862 00:51:37,200 --> 00:51:43,200 said is nonsense. So that's what worries me is how 863 00:51:43,200 --> 00:51:48,120 are we going to train the next generation if we're relying so 864 00:51:48,120 --> 00:51:52,240 much on coding assistance? So yeah, thanks for highlighting 865 00:51:52,240 --> 00:51:54,320 this apprenticeship. I kind of like agree with you, 866 00:51:54,320 --> 00:51:55,880 right? Because in some of my experience 867 00:51:55,880 --> 00:51:58,640 using coding assistance, sometimes, yeah, it got wrong 868 00:51:58,640 --> 00:52:01,200 answer in a confident way, you know, like this is it, you know, 869 00:52:01,240 --> 00:52:03,560 this is the solution. And then when you give it a try, 870 00:52:03,560 --> 00:52:04,640 actually it's kind of like wrong. 871 00:52:04,640 --> 00:52:07,960 You try again, it's still wrong until maybe certain times that 872 00:52:08,200 --> 00:52:11,280 OK, you finally got it right. So I think maybe people talk 873 00:52:11,280 --> 00:52:13,560 about, you know, replacing junior or junior being able to 874 00:52:13,560 --> 00:52:16,480 upscale themselves really, really fast just by using AI 875 00:52:16,480 --> 00:52:18,080 assistant. I think there's a worry there 876 00:52:18,080 --> 00:52:20,480 about this apprenticeship aspect that you mentioned, right? 877 00:52:20,640 --> 00:52:23,960 How can someone one be trained maybe in terms of abstraction, 878 00:52:23,960 --> 00:52:26,680 domain driven design or even evolutionary architecture, you 879 00:52:26,680 --> 00:52:28,160 know, the multiple dimension aspect. 880 00:52:28,440 --> 00:52:30,680 So I think AI currently is not capable of doing that. 881 00:52:30,920 --> 00:52:32,400 So thanks again for highlighting that. 882 00:52:32,840 --> 00:52:35,080 So Doctor Rebecca, it's been such a pleasure. 883 00:52:35,080 --> 00:52:37,000 I learned a lot about evolutionary architecture and 884 00:52:37,000 --> 00:52:40,320 all the fundamentals about it. So unfortunately, we reached the 885 00:52:40,320 --> 00:52:42,640 end of our conversation. I have one last question that 886 00:52:42,680 --> 00:52:45,040 I'd like to ask you. I call this the Tree Technical 887 00:52:45,040 --> 00:52:47,440 Leadership system. You can think of it just like an 888 00:52:47,440 --> 00:52:49,520 advice that you want to give to the listeners. 889 00:52:49,800 --> 00:52:52,880 Maybe you can share your version of wisdom for us to learn. 890 00:52:52,880 --> 00:52:57,520 From OK, well, the the first one is I firmly believe as 891 00:52:57,520 --> 00:53:01,960 technologists, it's our responsibility to communicate to 892 00:53:02,520 --> 00:53:07,680 the rest of the organization in their language the potential 893 00:53:07,840 --> 00:53:10,560 consequences of the decisions that they are making. 894 00:53:11,080 --> 00:53:14,840 We're the ones that know the tech, but we have to do it in in 895 00:53:14,840 --> 00:53:19,840 their language so that they can put it so they can understand 896 00:53:19,840 --> 00:53:24,080 the business risks and or the business opportunities for for 897 00:53:24,080 --> 00:53:26,400 that matter. And so the first thing is we 898 00:53:26,400 --> 00:53:31,160 need to understand how our organization makes money, what 899 00:53:31,160 --> 00:53:34,760 they are doing, what are the pressures on that organization 900 00:53:34,760 --> 00:53:39,360 and that's our responsibility. The second, I would say that as 901 00:53:39,360 --> 00:53:45,760 the technology landscape has become so broad, questions of 902 00:53:45,760 --> 00:53:49,040 generalists versus specialists have taken on a different 903 00:53:49,040 --> 00:53:52,480 meaning. It used to be, as I said when I 904 00:53:52,480 --> 00:53:57,720 started, one person could understand the entire stack. 905 00:53:58,760 --> 00:54:03,240 You can't do that to any level of specificity anymore. 906 00:54:03,840 --> 00:54:07,240 JavaScript frameworks and other front end frameworks and you 907 00:54:07,240 --> 00:54:10,600 know, non relational databases and this different kind of 908 00:54:10,600 --> 00:54:15,200 network architecture and dot dot dot dot dot, it just keeps going 909 00:54:15,200 --> 00:54:18,040 on. And so a a crucial decision that 910 00:54:18,040 --> 00:54:22,440 an individual needs to make is what kind of technologists do 911 00:54:22,440 --> 00:54:25,400 they want to be? Do they want to be a somewhat 912 00:54:25,400 --> 00:54:28,960 generalist? Do they want to think more big 913 00:54:28,960 --> 00:54:31,680 picture from a technology perspective, or do they want to 914 00:54:31,680 --> 00:54:34,440 become a true specialist in something? 915 00:54:34,840 --> 00:54:38,400 And that's something to decide relatively early in your career. 916 00:54:38,960 --> 00:54:43,600 And then the final thing is, with how rapidly our industry is 917 00:54:43,600 --> 00:54:47,440 changing, you have to think of learning as fun. 918 00:54:48,000 --> 00:54:50,960 I was one of those silly people who loved school, so summer 919 00:54:50,960 --> 00:54:53,520 school was perfect. We have summer and we have 920 00:54:53,520 --> 00:54:55,120 school at the same time as some of us. 921 00:54:55,120 --> 00:54:57,360 Great. And everybody thought I was mad. 922 00:54:58,160 --> 00:55:03,360 But we have to embrace that because new languages are coming 923 00:55:03,360 --> 00:55:06,640 out, new frameworks are coming out, new architectural 924 00:55:06,640 --> 00:55:12,640 approaches are coming out. And we need to be able and we 925 00:55:12,640 --> 00:55:16,760 need to enjoy continuing to learn new things because you 926 00:55:16,760 --> 00:55:21,240 don't want to be that person who is hanging on at the tail of the 927 00:55:21,240 --> 00:55:24,080 career because they're the only person left on the planet that 928 00:55:24,080 --> 00:55:25,920 understands this programming language. 929 00:55:26,520 --> 00:55:27,960 Yeah, you don't want to be that person. 930 00:55:28,520 --> 00:55:31,640 You want to be someone who has continued to evolve your career. 931 00:55:31,880 --> 00:55:36,560 And to do that, thinking of learning as fun and not a chore 932 00:55:36,640 --> 00:55:39,680 is crucial. Well, I wasn't expecting the 933 00:55:39,680 --> 00:55:42,280 last one, you know, treating learning as something fun, 934 00:55:42,280 --> 00:55:44,320 right? So I'm sure many people would 935 00:55:44,320 --> 00:55:46,160 find it also kind of like insightful, right? 936 00:55:46,160 --> 00:55:49,120 So if we don't take learning as something that we enjoy doing, I 937 00:55:49,120 --> 00:55:50,440 think it's kind of like a chore, right? 938 00:55:50,440 --> 00:55:53,040 Especially with all these rapid changes that are happening, I 939 00:55:53,040 --> 00:55:55,400 think it's going to be difficult to keep up if we don't treat it 940 00:55:55,400 --> 00:55:57,480 as a fun thing. So I think that's a really 941 00:55:57,480 --> 00:55:59,480 beautiful. So Doctor Rebecca, if people 942 00:55:59,480 --> 00:56:01,960 want to talk to you or maybe reach out to ask you more 943 00:56:01,960 --> 00:56:04,600 questions, is there a place where they can find you online? 944 00:56:05,160 --> 00:56:11,120 I'm on LinkedIn and my readable handle is Doctor Rebecca 945 00:56:11,120 --> 00:56:13,480 Parsons. Right, I'll put it in a show 946 00:56:13,480 --> 00:56:14,640 notes. So thank you so much for your 947 00:56:14,640 --> 00:56:16,320 time, Doctor Rebecca. I really enjoyed this. 948 00:56:16,320 --> 00:56:17,320 Conversation. Thank you, Henry. 949 00:56:17,960 --> 00:56:18,640 I had fun.