WEBVTT 1 00:00:00.120 --> 00:00:02.560 You know, I feel like it's pretty much a universal 2 00:00:02.600 --> 00:00:05.200 truth of the digital age that well, we all just 3 00:00:05.240 --> 00:00:06.360 want to build things quickly. 4 00:00:06.480 --> 00:00:07.919 Oh absolutely right, Like. 5 00:00:07.919 --> 00:00:09.759 You get this great idea, you sit down at your 6 00:00:09.839 --> 00:00:12.839 keyboard and you just want to immediately start writing code. 7 00:00:13.199 --> 00:00:16.600 It feels productive, it feels like you're, you know, actually 8 00:00:16.600 --> 00:00:17.239 making a thing. 9 00:00:17.440 --> 00:00:22.760 Yeah, the momentum is intoxicating. But jumping straight into a 10 00:00:22.800 --> 00:00:25.679 code editor like that, it's a lot like deciding to 11 00:00:25.679 --> 00:00:30.640 build a skyscraper and starting by just pouring a massive 12 00:00:30.679 --> 00:00:33.079 truckload of concrete into a random field. 13 00:00:33.200 --> 00:00:35.399 Yeah exactly. I mean you might end up with a wall, 14 00:00:35.439 --> 00:00:37.320 but you're probably just going to sink into a swamp. 15 00:00:37.399 --> 00:00:39.359 Right. It's a disaster waiting to happen. 16 00:00:39.479 --> 00:00:41.880 And that's why we're doing this deep dive today, because 17 00:00:41.920 --> 00:00:44.640 whether you are a junior programmer trying to level up, 18 00:00:44.799 --> 00:00:47.799 or maybe a team lead managing some huge project, or 19 00:00:47.920 --> 00:00:51.840 someone who's insanely curious about how these massive digital systems 20 00:00:51.880 --> 00:00:55.920 are built without you know, collapsing in on themselves. Understanding 21 00:00:55.960 --> 00:00:58.359 software architecture is the ultimate shortcut. 22 00:00:57.960 --> 00:01:00.159 It really is. It saves you from so much which 23 00:01:00.520 --> 00:01:02.640 disastrous expensive rework down the. 24 00:01:02.560 --> 00:01:06.599 Line exactly, So today we are diving into Michael Keeling's 25 00:01:06.599 --> 00:01:11.159 book Design It from Programmer to software architect, and our 26 00:01:11.239 --> 00:01:14.159 mission here is to figure out how to evolve from 27 00:01:14.359 --> 00:01:18.000 just writing code to truly designing software. 28 00:01:17.560 --> 00:01:21.920 Systems and spoiler alert for everyone listening, it involves a 29 00:01:21.920 --> 00:01:25.000 lot less typing and well, a whole lot more talking 30 00:01:25.040 --> 00:01:25.519 to humans. 31 00:01:25.680 --> 00:01:28.120 Yes, okay, let's unpack this. Yes, because I think there's 32 00:01:28.239 --> 00:01:31.519 this very stubborn myth in the tech world of the 33 00:01:32.680 --> 00:01:34.000 Ivory Tower architect. 34 00:01:34.120 --> 00:01:36.920 Oh yeah, the solitary wizard in the glass. 35 00:01:36.560 --> 00:01:39.840 Office, right, drawing these highly complex boxes and lines on 36 00:01:39.879 --> 00:01:42.280 a whiteboard, and then they just slide those diagrams under 37 00:01:42.319 --> 00:01:45.280 the door for the lowly developers to actually build. But 38 00:01:45.359 --> 00:01:47.640 Keeling completely dismantles that, doesn't he. 39 00:01:47.480 --> 00:01:49.480 He completely tears it down. I mean, it's a fundamental 40 00:01:49.519 --> 00:01:53.120 shift in perspective. When you're a programmer, your primary audience 41 00:01:53.280 --> 00:01:56.359 is the compiler. Your job is to give highly specific 42 00:01:56.359 --> 00:01:57.599 instructions to a machine. 43 00:01:57.680 --> 00:01:58.799 Right, it's you and the computer. 44 00:01:59.040 --> 00:02:02.120 Exactly. When you step into the role of a software architect, 45 00:02:02.359 --> 00:02:06.200 your primary audience suddenly becomes people. The technology is almost 46 00:02:06.200 --> 00:02:07.560 secondary to the sociology. 47 00:02:07.799 --> 00:02:10.800 I love that. So architecture isn't like being that wizard 48 00:02:10.960 --> 00:02:13.599 casting spells. It's more like being a city planner. 49 00:02:14.199 --> 00:02:15.400 That's a great way to look at it. 50 00:02:15.360 --> 00:02:18.919 Because you can design the coolest, most technologically advanced skyscraper 51 00:02:18.919 --> 00:02:22.159 in the world, but if it doesn't connect to the 52 00:02:22.240 --> 00:02:25.479 roads people actually drive on, or have plumbing that connects 53 00:02:25.479 --> 00:02:27.280 to the city grid, it's totally useless. 54 00:02:27.400 --> 00:02:29.680 Right, if you get the human element wrong, I don't 55 00:02:29.719 --> 00:02:32.199 care how elegant your code is, it just won't save you. 56 00:02:32.719 --> 00:02:36.319 Architecture is about understanding the humans using the system, the 57 00:02:36.400 --> 00:02:38.919 humans paying for it, and the humans building it. 58 00:02:39.120 --> 00:02:42.080 So how does an architect actually balance what the code 59 00:02:42.120 --> 00:02:44.719 needs with what all these different humans need? Because that 60 00:02:44.840 --> 00:02:45.759 sounds exhausting. 61 00:02:46.120 --> 00:02:48.800 What's fascinating here is that the human element doesn't just 62 00:02:49.319 --> 00:02:53.479 influence the code, it actively dictates it. Keeling brings in 63 00:02:53.560 --> 00:02:56.960 the heart principles of design thinking to navigate all this. 64 00:02:57.280 --> 00:02:59.960 Okay, heart, that's an acronym, right, let's break those down. 65 00:03:00.240 --> 00:03:03.400 Yeah, So hart HG is the human rule. It just 66 00:03:03.400 --> 00:03:06.039 reminds us that all design is a social activity. You're 67 00:03:06.039 --> 00:03:08.199 designing four people with people? 68 00:03:08.319 --> 00:03:09.520 Makes sense? What about the A. 69 00:03:09.840 --> 00:03:13.039 That's the ambiguity rule? This one is tough For engineers, 70 00:03:13.120 --> 00:03:17.400 it's about preserving ambiguity early on, to keep your options open, like, 71 00:03:17.479 --> 00:03:20.400 don't lock into a solution before you fully understand. 72 00:03:19.960 --> 00:03:23.039 The problem, right, don't jump to the code editor exactly. 73 00:03:23.879 --> 00:03:27.439 Then there's R for the redesign rule. This acknowledges that 74 00:03:27.560 --> 00:03:31.680 all design is essentially redesigning known patterns. We really aren't 75 00:03:31.719 --> 00:03:34.680 reinventing the wheel every time. And the t T is 76 00:03:34.719 --> 00:03:39.560 the tangibility rule making abstract ideas real. So drawing sketches 77 00:03:39.599 --> 00:03:41.840 are building models so people can actually point at them 78 00:03:41.840 --> 00:03:44.000 and talk about them. The good architect is really a 79 00:03:44.080 --> 00:03:47.240 mentor and a collaborator, not a dictator. 80 00:03:47.000 --> 00:03:49.639 So they're constantly just trying to understand what the stakeholders 81 00:03:49.680 --> 00:03:51.360 actually want in the real world. 82 00:03:51.280 --> 00:03:55.080 Yes, exactly, through tools like empathy mapping and stakeholder maps. 83 00:03:55.560 --> 00:03:57.800 Keeling uses a great case study in the book called 84 00:03:57.840 --> 00:04:00.879 Project Lionheart. Oh right with the Yeah, you have the 85 00:04:00.879 --> 00:04:02.759 mayor of the city, a guy named Jean Claude van 86 00:04:02.840 --> 00:04:05.000 Dam and no relation to. 87 00:04:04.960 --> 00:04:07.560 The actor, which is a shame honestly true. 88 00:04:07.759 --> 00:04:10.719 But anyway, he wants to modernize the city's Office of 89 00:04:10.759 --> 00:04:17.560 Management and Budget. His goal cut procurement costs by thirty percent. 90 00:04:17.319 --> 00:04:19.279 Okay, Chris, standard executive. 91 00:04:18.759 --> 00:04:21.399 Goal, right, But then you look at the actual end users, 92 00:04:21.439 --> 00:04:24.480 the people doing the work in that office. Their primary 93 00:04:24.519 --> 00:04:27.480 pain point is that it takes them six weeks to 94 00:04:27.519 --> 00:04:31.279 publish a single a riding request for proposal. 95 00:04:31.399 --> 00:04:34.759 Oh wow, so those are totally conflicting motivation completely. I mean, 96 00:04:34.800 --> 00:04:37.279 the mayor wants a cheap a process, but the users 97 00:04:37.360 --> 00:04:40.279 desperately want a faster process. If you only listen to 98 00:04:40.319 --> 00:04:42.800 the mayor, you build a cheap system that is slow 99 00:04:43.040 --> 00:04:44.279 and miserable to use. 100 00:04:44.319 --> 00:04:46.240 And if you only listen to the users, you build 101 00:04:46.240 --> 00:04:49.240 a lightning fast system that completely bankrupts the city. 102 00:04:49.399 --> 00:04:52.399 Right, And that tension right there is exactly why empathy 103 00:04:52.439 --> 00:04:54.720 mapping is so critical. You have to map out those 104 00:04:54.759 --> 00:04:58.439 conflicting needs because they directly shape the technical constraints of 105 00:04:58.439 --> 00:04:59.560 the system you're about to build. 106 00:04:59.560 --> 00:05:02.040 Exactly. You can't code your way out of a fundamentally 107 00:05:02.120 --> 00:05:03.040 human disagreement. 108 00:05:03.240 --> 00:05:06.399 But wait, if human needs are this complex and they're 109 00:05:06.439 --> 00:05:10.040 constantly conflicting, how do we ever decide when to stop 110 00:05:10.079 --> 00:05:14.000 talking and start typing? Because you know, developers, we get 111 00:05:14.079 --> 00:05:16.480 very antsy, oh very antsy, Like if we try to 112 00:05:16.519 --> 00:05:19.720 perfectly map every single human emotion to a piece of code. 113 00:05:19.920 --> 00:05:21.879 We're going to be planning until the heat death of 114 00:05:21.920 --> 00:05:22.560 the universe. 115 00:05:22.639 --> 00:05:25.079 Yeah, and that brings us to a really important concept 116 00:05:25.120 --> 00:05:28.079 called bounded rationality. It was coined by a guy named 117 00:05:28.120 --> 00:05:28.800 Herbert Simon. 118 00:05:29.120 --> 00:05:31.720 Bounded rationality. What does that mean? In this context? 119 00:05:31.800 --> 00:05:35.439 It's basically the realization that humans have hard limits. We 120 00:05:35.519 --> 00:05:40.920 have limits in time, money, cognitive capacity, and just available knowledge. 121 00:05:41.399 --> 00:05:45.519 Because of bounded rationality, it is mathematically impossible to find 122 00:05:45.519 --> 00:05:49.279 the single optimal design for a complex software system. 123 00:05:49.399 --> 00:05:51.439 Okay, so perfection is a literal. 124 00:05:51.160 --> 00:05:54.879 Myth, a literal mathematical impossibility. So instead of chasing this 125 00:05:54.959 --> 00:05:59.560 perfect optimal design, architects look for a design that satisfies, satisfices. 126 00:05:59.600 --> 00:06:00.000 I love that one. 127 00:06:00.360 --> 00:06:03.319 It's great, right, It's a portmanteau of satisfactory and sufficient. 128 00:06:03.600 --> 00:06:05.879 You look for a design that is good enough to 129 00:06:06.079 --> 00:06:10.120 solve the primary problems and reduce your major risks, and 130 00:06:10.160 --> 00:06:10.920 then you just move on. 131 00:06:11.240 --> 00:06:13.600 Okay, here's where it gets really interesting to me, because 132 00:06:13.600 --> 00:06:15.240 I want to push back on behalf of all the 133 00:06:15.360 --> 00:06:18.560 impatient developers listening right now, go for There is this 134 00:06:18.720 --> 00:06:23.560 famous saying in agile software development, Right, a month of 135 00:06:23.639 --> 00:06:25.720 coding can save an hour. 136 00:06:25.639 --> 00:06:28.160 Of architecting, right. The classic joke. 137 00:06:28.120 --> 00:06:30.160 Yeah, the joke being that if you just start building, 138 00:06:30.199 --> 00:06:32.399 you'll figure it out as you go. So why don't 139 00:06:32.439 --> 00:06:35.240 we just build things quickly, get it in front of users, 140 00:06:35.319 --> 00:06:37.439 and fix it later when we actually know what the 141 00:06:37.480 --> 00:06:38.519 real world problems are. 142 00:06:38.959 --> 00:06:42.519 It is very tempting philosophy, especially in start of culture. Yeah, 143 00:06:42.600 --> 00:06:47.199 but the data just completely destroys it. Keeling brings in 144 00:06:47.240 --> 00:06:49.959 this research from Barry Bahem on the sweet spot of 145 00:06:50.040 --> 00:06:52.680 design time, and the numbers are just staggering. 146 00:06:52.959 --> 00:06:53.800 Lay the numbers on me. 147 00:06:53.879 --> 00:06:56.519 Okay, imagine you have one hundred day schedule for a 148 00:06:56.560 --> 00:06:59.399 medium to large project. Let's say it's about one hundred 149 00:06:59.399 --> 00:06:59.839 thousand lines. 150 00:07:00.360 --> 00:07:02.319 Okay, one hundred days pretty standard. 151 00:07:02.519 --> 00:07:06.079 If you spend just five percent of your time, so 152 00:07:06.560 --> 00:07:09.480 five days on architecture, you will end up increasing your 153 00:07:09.480 --> 00:07:11.399 total schedule by forty three percent. 154 00:07:11.480 --> 00:07:12.959 Wait, forty three percent. 155 00:07:12.759 --> 00:07:17.800 Yes, due to massive expensive rework. You build the wrong thing, 156 00:07:18.120 --> 00:07:20.680 you realize it doesn't scale, you have to tear it down, 157 00:07:20.959 --> 00:07:23.439 you break other things in the process, and you basically 158 00:07:23.480 --> 00:07:23.959 start over. 159 00:07:24.199 --> 00:07:26.560 Oh my god. So trying to save time by rushing 160 00:07:26.560 --> 00:07:29.959 the design phase actually adds almost half the project time 161 00:07:30.000 --> 00:07:31.040 back on in penalties. 162 00:07:31.079 --> 00:07:34.240 That is brutal, it really is. But it gets better 163 00:07:34.560 --> 00:07:37.759 if you increase your upfront architecture time to seventeen percent, 164 00:07:37.839 --> 00:07:40.079 so seventeen days out of the one hundred, the total 165 00:07:40.120 --> 00:07:42.279 schedule increase drops to thirty eight percent. 166 00:07:42.399 --> 00:07:44.680 Okay, think about that math for a second. You spend 167 00:07:44.759 --> 00:07:48.199 more time planning upfront, but your overall delivery time goes 168 00:07:48.240 --> 00:07:50.759 down because you aren't doing all that rework exactly. 169 00:07:50.839 --> 00:07:52.519 It saves you time in the long run. 170 00:07:52.319 --> 00:07:55.639 But you can't just plan forever, right, because, like we said, 171 00:07:55.759 --> 00:07:57.600 bounded rationality correct. 172 00:07:57.839 --> 00:08:00.240 Boem's data also shows that if you spend thirty three 173 00:08:00.240 --> 00:08:04.079 percent of your time on architecture, you hit severe diminishing returns. 174 00:08:04.560 --> 00:08:08.160 The schedule inflates again because of analysis paralysis. 175 00:08:08.360 --> 00:08:10.800 Right, you're just staring at a whiteboard making no progress. 176 00:08:10.920 --> 00:08:13.680 Yeah, so there's a mathematical sweet spot and it's usually 177 00:08:13.680 --> 00:08:15.759 around fifteen to twenty percent of the project time. 178 00:08:16.040 --> 00:08:19.160 Okay, I buy the sweet spot, but seventeen days is 179 00:08:19.199 --> 00:08:21.519 still a long time to just stare at a whiteboard. 180 00:08:22.279 --> 00:08:24.879 How does an architect know what to actually focus on 181 00:08:25.000 --> 00:08:27.319 during that time so they aren't just you know, spinning 182 00:08:27.360 --> 00:08:28.399 their Reels. 183 00:08:28.399 --> 00:08:32.559 Well, you focus on risk. Risk driven architecture is how 184 00:08:32.559 --> 00:08:36.720 you decide when to stop designing. Keeling offers this brilliant, 185 00:08:36.799 --> 00:08:39.480 simple framework for identifying engineering risks. 186 00:08:39.559 --> 00:08:40.200 How does it work? 187 00:08:40.519 --> 00:08:44.480 It uses a condition might consequence format. So, for example, 188 00:08:44.559 --> 00:08:48.240 here's one from the book. Condition a new burrito restaurant 189 00:08:48.279 --> 00:08:52.080 opened across the street. Consequence the team might get sick 190 00:08:52.159 --> 00:08:53.360 eating too many burritos. 191 00:08:53.519 --> 00:08:57.360 That is a highly realistic engineering risk, absolutely. 192 00:08:57.080 --> 00:09:00.120 But notice how specific it is. It's not just I 193 00:09:00.120 --> 00:09:03.320 have a bad feeling about lunch. By identifying the specific 194 00:09:03.360 --> 00:09:07.039 condition and the potential consequence, an architect can actually mitigate 195 00:09:07.039 --> 00:09:07.600 it right, Like. 196 00:09:07.519 --> 00:09:09.720 Maybe you cater lunch on release days so the team 197 00:09:09.759 --> 00:09:11.720 doesn't go eat the risky burritos. 198 00:09:11.919 --> 00:09:16.080 Up exactly in software, Once the major architectural risks are 199 00:09:16.080 --> 00:09:19.879 reduced to an acceptable level, you stop actively designing. You 200 00:09:19.919 --> 00:09:22.039 shift to what he calls passive design. 201 00:09:22.360 --> 00:09:25.080 Passive design meaning what they just sit back and. 202 00:09:25.039 --> 00:09:28.840 Watch kind of. The team starts writing code and the 203 00:09:28.960 --> 00:09:32.679 architect simply monitors the system to ensure the original assumptions 204 00:09:32.720 --> 00:09:33.120 hold up. 205 00:09:33.240 --> 00:09:36.000 Okay, so we use risk to figure out when to 206 00:09:36.039 --> 00:09:39.240 stop designing. But that naturally leads to the question of 207 00:09:39.279 --> 00:09:42.399 what we are actually measuring those risks against, which means 208 00:09:42.440 --> 00:09:44.039 we need to talk about asrs. 209 00:09:44.320 --> 00:09:47.759 Ah. Yes, architecturally significant requirement. 210 00:09:47.960 --> 00:09:51.879 Right, so what exactly makes a requirement architecturally significant? 211 00:09:51.919 --> 00:09:55.080 Asrs are the foundation. These are the requirements that will 212 00:09:55.120 --> 00:09:57.480 literally force you to raise your architecture to the ground 213 00:09:57.519 --> 00:09:59.960 and start over if you get them wrong. Keeling break 214 00:10:00.120 --> 00:10:00.960 them into four types. 215 00:10:01.000 --> 00:10:02.080 Okay, let's walk through those. 216 00:10:02.200 --> 00:10:07.240 You have constraints, quality attributes, influential functional requirements, and other influencers. 217 00:10:07.519 --> 00:10:10.399 Constraints seems pretty self explanatory. 218 00:10:09.759 --> 00:10:13.320 Right, Yeah. Constraints are unchangeable facts. Like the mayor says, 219 00:10:13.360 --> 00:10:15.960 Projects Linehart must be open source. You can't negotiate that. 220 00:10:16.320 --> 00:10:18.559 It limits your technology choices right out of the gate. 221 00:10:18.720 --> 00:10:21.279 What about influential functional requirements? 222 00:10:21.519 --> 00:10:24.840 Those are specific features that bend the whole system. So, 223 00:10:24.960 --> 00:10:28.000 for example, if your app needs to process credit. 224 00:10:27.720 --> 00:10:30.279 Cards, right, that's not just a simple button. 225 00:10:30.120 --> 00:10:35.039 No, it introduces massive security compliances, third party API integrations 226 00:10:35.399 --> 00:10:38.679 and data encryption standards that change the entire shape of 227 00:10:38.679 --> 00:10:41.840 your database. And other influencers That might be things like 228 00:10:41.879 --> 00:10:45.440 the existing skills of your team or maybe legacy systems 229 00:10:45.440 --> 00:10:46.840 you're forced to integrate. 230 00:10:46.480 --> 00:10:48.759 With got it, but the heavy hitter. The one the 231 00:10:48.759 --> 00:10:52.759 book focuses on most is quality attributes. These are the 232 00:10:53.000 --> 00:10:54.120 ellibilities right. 233 00:10:54.039 --> 00:10:58.320 Yes, scalability, availability, maintainability, portability, all the alliblities. 234 00:10:58.440 --> 00:11:01.000 And the crucial lesson here is that you cannot just 235 00:11:01.039 --> 00:11:03.879 write down We need it to be portable on a 236 00:11:03.879 --> 00:11:07.000 sticky note. I mean that means absolutely nothing to a developer. 237 00:11:06.840 --> 00:11:09.759 Nothing at all. You have to be incredibly precise. The 238 00:11:09.799 --> 00:11:13.919 book brings in this amazing scenario from the NASA Jet 239 00:11:13.960 --> 00:11:16.159 Propulsion Laboratory for a Mars rover. 240 00:11:16.399 --> 00:11:18.480 Oh I love this part. It shows how specific you 241 00:11:18.480 --> 00:11:19.600 have to be exactly. 242 00:11:20.159 --> 00:11:24.799 They define a highly specific six part scenario just for portability. 243 00:11:26.080 --> 00:11:28.720 The stimulus is running a test suite on a new 244 00:11:28.759 --> 00:11:32.480 hardware platform. The source of the stimulus is the test team. 245 00:11:33.320 --> 00:11:36.360 The artifact being tested is the mission flight control system. 246 00:11:36.440 --> 00:11:37.919 It's so detailed it goes on. 247 00:11:38.360 --> 00:11:41.120 The response is that the system runs on the new hardware. 248 00:11:41.360 --> 00:11:43.919 The response measure, and this is the critical part, is 249 00:11:43.960 --> 00:11:47.519 that all tests pass with no code changes. And the 250 00:11:47.639 --> 00:11:49.480 environment is the testing lab that. 251 00:11:49.480 --> 00:11:51.879 Is surgically precise, like you can actually write a test 252 00:11:51.919 --> 00:11:53.519 for that. Yeah, but it also means you have to 253 00:11:53.519 --> 00:11:57.600 make choices, because obviously you can't have infinite scalability, perfect security, 254 00:11:57.720 --> 00:11:58.799 and instant performance all. 255 00:11:58.720 --> 00:12:01.120 At the same time as trade offs, which. 256 00:12:00.960 --> 00:12:03.360 Brings up my absolute favorite analogy in the whole book. 257 00:12:03.360 --> 00:12:04.200 The chainsaw blender. 258 00:12:04.279 --> 00:12:06.039 Oh the ultimate lesson in trade offs. 259 00:12:06.399 --> 00:12:09.240 Right, So, imagine you want to make a smoothie. You 260 00:12:09.240 --> 00:12:11.320 have a standard kitchen blender. It sits on your counter. 261 00:12:11.399 --> 00:12:14.799 It's quiet, it's safe, but you know it's tethered to an. 262 00:12:14.600 --> 00:12:16.399 Electrical outlet, very restricted. 263 00:12:16.519 --> 00:12:19.559 Then you have a battery powered hand blender. It's portable, 264 00:12:19.639 --> 00:12:21.799 you can take it camping, but it's really weak it 265 00:12:21.799 --> 00:12:25.919 won't crush ice. And then you have the chainsaw blender. 266 00:12:26.600 --> 00:12:31.000 You attach a blender pitcher to a gas powered two 267 00:12:31.039 --> 00:12:36.519 stroke motorcycle throttle chainsaw engine naturally, Naturally, it is insanely powerful. 268 00:12:36.600 --> 00:12:39.960 It is entirely portable, but it is horribly loud, it 269 00:12:40.080 --> 00:12:44.720 spews toxic exhaust, and it is wildly unsafe for indoor use. 270 00:12:44.840 --> 00:12:45.720 A slight drawback. 271 00:12:45.960 --> 00:12:47.840 Right, So, if someone tells me they want a blender, 272 00:12:47.840 --> 00:12:49.799 and I build them a chainsaw blender, because I assumed 273 00:12:49.840 --> 00:12:53.240 their primary goal was power, I have completely failed. If 274 00:12:53.240 --> 00:12:56.279 their actual goal was just making a quiet safe morning 275 00:12:56.320 --> 00:12:57.559 smoothie exactly. 276 00:12:58.000 --> 00:12:59.919 And if we connect this to the bigger picture, the 277 00:13:00.120 --> 00:13:04.519 chainsaw blender illustrates that every single architectural decision trades one 278 00:13:04.600 --> 00:13:08.440 quality attribute for another. You trade safety and quietness for 279 00:13:08.559 --> 00:13:09.600 power and portability. 280 00:13:09.919 --> 00:13:12.200 So how do we make sure we aren't building chainsaw 281 00:13:12.240 --> 00:13:14.840 blenders for people who just want a quiet smoothie. 282 00:13:15.200 --> 00:13:18.879 Architects use a tool called a decision matrix to visually 283 00:13:18.919 --> 00:13:20.159 map these trade offs out. 284 00:13:20.480 --> 00:13:23.440 How does a decision matrix actually work in practice? Like 285 00:13:23.519 --> 00:13:25.240 in a room full of engineers, you. 286 00:13:25.200 --> 00:13:28.879 List your architectural pattern options on one axis, say a 287 00:13:28.919 --> 00:13:32.559 three tier pattern, a published subscribe pattern and apports an 288 00:13:32.600 --> 00:13:35.240 adapter's pattern, and then on the other axis you list 289 00:13:35.279 --> 00:13:40.200 the quality attributes you prioritize, like maintainability, scalability, and performance. 290 00:13:40.759 --> 00:13:41.600 Then you score them. 291 00:13:41.679 --> 00:13:43.559 And this is where we actually need to explain how 292 00:13:43.600 --> 00:13:46.759 these patterns work mechanically, because they aren't just you know, buzzwords. 293 00:13:46.879 --> 00:13:50.600 Let's do it. Three tier pattern separates your system into 294 00:13:50.639 --> 00:13:54.399 presentation which is the user interface, logic which is the brain, 295 00:13:55.039 --> 00:13:56.679 and data the database. 296 00:13:56.840 --> 00:13:58.399 Pretty standard it is. 297 00:13:58.919 --> 00:14:02.080 It's great for maintainability because they're separate, but if millions 298 00:14:02.080 --> 00:14:05.480 of users hit it at once. It can really bottleneck. Now, 299 00:14:05.519 --> 00:14:09.279 look at published subscribe or pubsub. 300 00:14:08.879 --> 00:14:10.039 Okay, how does that one work? 301 00:14:10.159 --> 00:14:13.440 Think of it like a magazine subscription. A data producer 302 00:14:13.519 --> 00:14:16.559 just publishes a message to a central hub and it 303 00:14:16.600 --> 00:14:19.519 doesn't care who reads it. The consumers just subscribe to 304 00:14:19.519 --> 00:14:20.759 the hub to get their copies. 305 00:14:21.080 --> 00:14:24.519 So the publisher and the subscriber never actually talk directly 306 00:14:24.559 --> 00:14:26.080 to each other exactly. 307 00:14:26.159 --> 00:14:28.720 It's incredibly flexible and scalable because you can add a 308 00:14:28.759 --> 00:14:32.879 thousand subscribers without touching the publisher. But it trades off 309 00:14:32.919 --> 00:14:34.879 strict data consistency. 310 00:14:34.320 --> 00:14:37.000 Because you can't guarantee exactly when a subscriber actually reads 311 00:14:37.039 --> 00:14:37.600 the message. 312 00:14:37.679 --> 00:14:40.240 Right. Then you have ports and adapters, which is also 313 00:14:40.279 --> 00:14:43.120 called hexagonal architecture. Imagine you have a core piece of 314 00:14:43.200 --> 00:14:46.879 logic that calculates taxes. The port is the interface plug, 315 00:14:47.279 --> 00:14:50.000 and the adapter is a piece of code that translates 316 00:14:50.000 --> 00:14:54.320 SQL database data into a format your tax calculator can read. 317 00:14:54.440 --> 00:14:56.919 So if I want to switch from a SQL database 318 00:14:56.960 --> 00:14:59.440 to a no SQL database tomorrow, I don't have to 319 00:14:59.440 --> 00:15:01.639 rewrite my time logic. I just write a new adapter 320 00:15:01.720 --> 00:15:02.279 to plug. 321 00:15:02.080 --> 00:15:06.360 Into the port precisely. It gives you incredible testability and isolation. 322 00:15:07.279 --> 00:15:10.120 But it requires writing a lot of extra boilerplate code 323 00:15:10.159 --> 00:15:13.960 for all those adapters. So the decision matrix forces the 324 00:15:14.000 --> 00:15:17.519 team to look at the mechanics of these patterns and 325 00:15:17.720 --> 00:15:20.919 visually acknowledge what they're giving up to get what they want. 326 00:15:21.120 --> 00:15:24.720 It ensures you don't build a chainsaw blender by accident exactly. 327 00:15:24.759 --> 00:15:28.080 That makes the redesigned rule of heart makes so much sense. 328 00:15:28.600 --> 00:15:30.960 We aren't inventing new shapes, we are just picking the 329 00:15:31.039 --> 00:15:35.120 right established pattern. But Keeling also warns about an anti pattern, 330 00:15:35.159 --> 00:15:38.120 doesn't he the dreaded big ball of mud. 331 00:15:38.279 --> 00:15:41.279 Oh, the big ball of mud that is the default 332 00:15:41.360 --> 00:15:43.720 architecture of a system that wasn't designed at all. It's 333 00:15:43.759 --> 00:15:47.720 just a tangle of undisciplined coding, unchecked technical debt, and 334 00:15:47.919 --> 00:15:49.559 completely bypassed patterns. 335 00:15:49.679 --> 00:15:50.720 Basically a nightmare. 336 00:15:50.919 --> 00:15:52.840 Yeah, every piece of code is glued to every other 337 00:15:52.879 --> 00:15:54.240 piece of code, so if you try to fix a 338 00:15:54.279 --> 00:15:56.919 tiny bug in the login screen, you somehow break the 339 00:15:57.000 --> 00:15:57.720 checkout cart. 340 00:15:57.840 --> 00:16:00.360 But wait, I see a paradox here and say, we 341 00:16:00.440 --> 00:16:02.840 do everything right, We map our human needs, we use 342 00:16:02.879 --> 00:16:06.080 our decision matrix, and we pick a highly decoupled, beautiful 343 00:16:06.120 --> 00:16:09.919 published subscribe pattern. But then there's Conway's law. 344 00:16:10.159 --> 00:16:14.639 Ah. Conway's law the inescapable gravity of software engineering. 345 00:16:14.720 --> 00:16:14.840 Right. 346 00:16:15.240 --> 00:16:18.519 It states that a system's designed will inevitably mimic the 347 00:16:18.519 --> 00:16:21.200 communication structures of the organization building it. 348 00:16:21.519 --> 00:16:25.200 So, if I pick that beautiful pub sub pattern on paper, 349 00:16:25.639 --> 00:16:29.759 but my actual human development teams are completely siloed, they 350 00:16:29.799 --> 00:16:33.279 hate each other, and they never communicate, Conway's law says, 351 00:16:33.320 --> 00:16:35.440 my architecture is going to fail anyway. It's just going 352 00:16:35.519 --> 00:16:36.600 to mimic their dysfunction. 353 00:16:36.879 --> 00:16:40.320 Yes. Absolutely, if you have three teams that don't communicate, 354 00:16:40.840 --> 00:16:45.639 you will inevitably build a system with three disconnected, incompatible components, 355 00:16:46.000 --> 00:16:49.559 regardless of what that whiteboard diagram says. Conway's law is 356 00:16:49.559 --> 00:16:52.600 a two way street. If you, as the architect, want 357 00:16:52.639 --> 00:16:55.919 to change the technical architecture of the software, you very 358 00:16:55.960 --> 00:16:59.000 often have to reorganize the human teams building it. You 359 00:16:59.000 --> 00:17:01.960 have to align the human communication paths with the desired 360 00:17:02.000 --> 00:17:03.559 software communication. 361 00:17:03.120 --> 00:17:05.519 Paths, which brings us completely full circle back to the 362 00:17:05.559 --> 00:17:09.240 heart principles. The human element is inseparable from the technical patterns. 363 00:17:09.279 --> 00:17:12.400 You literally cannot fix the code without fixing the people. 364 00:17:12.279 --> 00:17:15.960 Which is exactly why in architect's most vital tool isn't 365 00:17:15.960 --> 00:17:19.319 a coding language at all. It's a shared vocabulary. To 366 00:17:19.440 --> 00:17:22.839 overcome Conway's law and prevent that big ball of mud, 367 00:17:23.440 --> 00:17:26.599 the team needs a common meta model. They have to 368 00:17:26.640 --> 00:17:27.759 agree on what things. 369 00:17:27.519 --> 00:17:30.839 Are called, which sounds easy, but developers love to argue 370 00:17:30.839 --> 00:17:32.000 about naming conventions. 371 00:17:32.000 --> 00:17:32.640 Well, they love it. 372 00:17:33.000 --> 00:17:36.440 The book breaks this down using Arlow Belshie's Seven Stages 373 00:17:36.480 --> 00:17:39.319 of naming, which I found fascinating. It shows how the 374 00:17:39.400 --> 00:17:42.720 literal name of a variable in your code evolves as 375 00:17:42.799 --> 00:17:45.319 your human understanding of the system evolves. 376 00:17:45.599 --> 00:17:47.839 Naming is actually a great metric for how well you 377 00:17:47.920 --> 00:17:51.519 understand your own design. The first stage is missing. You 378 00:17:51.519 --> 00:17:53.720 don't even know enough to name the concept yet. Stage 379 00:17:53.759 --> 00:17:58.200 two is nonsense, nonsense like what well bellschie uses the 380 00:17:58.240 --> 00:18:01.559 example of naming a component cranbar cranberry. Yeah, it means 381 00:18:01.599 --> 00:18:04.200 absolutely nothing. It's just a placeholder. So the code compiles. 382 00:18:04.720 --> 00:18:07.119 But as you refine the architecture, you move through stages 383 00:18:07.160 --> 00:18:10.400 like honest and honest and complete, where the name describes 384 00:18:10.480 --> 00:18:12.079 mechanically what the code does. 385 00:18:12.240 --> 00:18:15.839 Like naming it data fetcher, checker, transformer and job starter. 386 00:18:16.400 --> 00:18:19.440 It's honest, but I mean it's incredibly clunky because you 387 00:18:19.480 --> 00:18:22.759 are still thinking like a machine. The ultimate goal is 388 00:18:22.759 --> 00:18:27.559 Stage seven domain abstraction. Instead of that clanky name, you 389 00:18:27.680 --> 00:18:30.920 realize what the component truly is in the context of 390 00:18:30.960 --> 00:18:34.440 the business domain. You reach a profound abstraction and name 391 00:18:34.480 --> 00:18:36.599 it something like data preparation Agent. 392 00:18:36.759 --> 00:18:40.279 Ah. So suddenly anyone looking at the code knows exactly 393 00:18:40.319 --> 00:18:42.599 what its purpose is without having to read one hundred 394 00:18:42.680 --> 00:18:45.519 lines of logic exactly. But how do you get a 395 00:18:45.599 --> 00:18:49.400 whole team of very opinionated engineers to arrive at those 396 00:18:49.440 --> 00:18:53.240 stage seven names and agree on complex patterns before the 397 00:18:53.279 --> 00:18:55.519 project just runs out of money? I mean, you can't 398 00:18:55.519 --> 00:18:57.200 just debate it in a conference room forever. 399 00:18:57.720 --> 00:19:00.079 That brings us to the sharette, also known as the 400 00:19:00.160 --> 00:19:01.279 architecture design studio. 401 00:19:01.640 --> 00:19:04.279