WEBVTT 00:00:00.000 --> 00:00:02.160 You know, usually when we talk about diagnosing 00:00:02.160 --> 00:00:05.240 a problem, like say a medical diagnosis, there's 00:00:05.240 --> 00:00:07.719 this expectation of precision. Right. It feels 00:00:07.719 --> 00:00:10.939 clean. Very objective. Yeah, exactly. You break 00:00:10.939 --> 00:00:13.320 your arm, the x -ray shows that jagged white 00:00:13.320 --> 00:00:15.419 line, the doctor points to it, and that's it. 00:00:15.779 --> 00:00:18.160 You know exactly what's wrong. And you know exactly 00:00:18.160 --> 00:00:20.440 what needs to be fixed. We really do like things 00:00:20.440 --> 00:00:23.620 to be visible. you know, to be categorized easily. 00:00:23.839 --> 00:00:26.239 Well, the human brain craves that kind of binary 00:00:26.239 --> 00:00:28.800 simplicity. I mean, it is either broken or it 00:00:28.800 --> 00:00:30.940 is not broken. Right. But then you step into 00:00:30.940 --> 00:00:34.929 the world of software development or really any 00:00:34.929 --> 00:00:37.310 complex system management, and you are staring 00:00:37.310 --> 00:00:39.630 at a product with hundreds of thousands of users. 00:00:39.890 --> 00:00:42.090 Oh yeah, suddenly that pristine x -ray machine 00:00:42.090 --> 00:00:44.469 is completely useless. Totally useless. Yeah. 00:00:44.590 --> 00:00:46.630 You are looking at a diagnostic landscape that 00:00:46.630 --> 00:00:49.149 is entirely chaotic. Because you've got this 00:00:49.149 --> 00:00:51.710 massive segment of users screaming on social 00:00:51.710 --> 00:00:55.250 media about like a typo on the homepage. Exactly. 00:00:55.450 --> 00:00:58.310 While somewhere deep in the server, a silent 00:00:58.310 --> 00:01:01.369 error is slowly corrupting critical financial 00:01:01.369 --> 00:01:04.840 data. And when every single dashboard is flashing 00:01:04.840 --> 00:01:08.019 red and every user thinks their specific problem 00:01:08.019 --> 00:01:10.480 is the absolute end of the world. Which they 00:01:10.480 --> 00:01:13.120 always do. Right, they always do. Relying on 00:01:13.120 --> 00:01:15.640 intuition or just the volume of complaints is 00:01:15.640 --> 00:01:18.439 a guaranteed way to fail. You need a mechanism 00:01:18.439 --> 00:01:20.500 to decide what actually needs your attention 00:01:20.500 --> 00:01:23.750 first. Without letting panic... dictate the workflow. 00:01:24.450 --> 00:01:26.650 And, you know, that is the exact chaos we are 00:01:26.650 --> 00:01:28.590 cutting through today. Welcome to this deep dive. 00:01:28.709 --> 00:01:30.569 Glad to be here for this one. It's a fun topic. 00:01:30.609 --> 00:01:34.370 It really is because today we are cracking open 00:01:34.370 --> 00:01:38.450 a highly specific mathematical framework used 00:01:38.450 --> 00:01:41.420 by software testers. It's used to bring objective 00:01:41.420 --> 00:01:44.219 order to that exact kind of overwhelming situation. 00:01:44.219 --> 00:01:46.379 And I have to say, the single source we're using 00:01:46.379 --> 00:01:49.060 today is beautifully ironic. Oh, it's so good. 00:01:49.299 --> 00:01:51.439 We are pulling from a Wikipedia article simply 00:01:51.439 --> 00:01:54.599 titled Defect Criticality. It is a phenomenal 00:01:54.599 --> 00:01:57.719 example of a text embodying the very problem 00:01:57.719 --> 00:01:59.959 it is trying to solve. It really is. Because 00:01:59.959 --> 00:02:02.040 think about it. It's an article entirely about 00:02:02.040 --> 00:02:05.420 software quality control, right? About identifying, 00:02:05.659 --> 00:02:08.620 prioritizing, and fixing flaws. But the article 00:02:08.620 --> 00:02:11.240 itself is flagged by Wikipedia for having its 00:02:11.240 --> 00:02:14.159 own glaring defects. It's incredible. At the 00:02:14.159 --> 00:02:16.520 very top, it is plastered with these warning 00:02:16.520 --> 00:02:19.560 banners. One says it has been lacking citations 00:02:19.560 --> 00:02:23.039 since April 2015. A whole decade ago. Yeah. And 00:02:23.039 --> 00:02:25.780 the other banner says it has had unclear notability 00:02:25.780 --> 00:02:29.800 since August 2025. It is an article about identifying 00:02:29.800 --> 00:02:32.919 flaws, wearing its own flaws right on its sleeve. 00:02:33.159 --> 00:02:35.819 Yet, despite those warnings, the actual text 00:02:35.819 --> 00:02:39.099 contains a remarkably elegant, masterclass -level 00:02:39.099 --> 00:02:42.099 framework for triage and prioritization. Exactly. 00:02:42.479 --> 00:02:45.419 So, our mission today is to extract this specific 00:02:45.419 --> 00:02:47.520 framework and show you how it can completely 00:02:47.520 --> 00:02:49.439 change how you look at problem solving. And not 00:02:49.439 --> 00:02:51.800 just in code, but in your own daily life. Okay, 00:02:51.860 --> 00:02:54.180 let's unpack this. What exactly is this metric? 00:02:54.430 --> 00:02:57.969 And how does it separate the noise from the actual 00:02:57.969 --> 00:03:00.189 emergencies? Well, what's fascinating here is 00:03:00.189 --> 00:03:02.449 that the framework physically prevents developers 00:03:02.449 --> 00:03:04.889 from just fixing what is annoying the loudest 00:03:04.889 --> 00:03:06.330 customer. Which is human nature, right? Yeah. 00:03:06.469 --> 00:03:10.020 To just make the yelling stop. Totally. But defect 00:03:10.020 --> 00:03:13.400 criticality, officially, is a metric used in 00:03:13.400 --> 00:03:16.639 software quality assessment to quantify the potential 00:03:16.639 --> 00:03:19.319 impact of a software defect. So it translates 00:03:19.319 --> 00:03:22.780 a feeling of panic into a hard, objective number. 00:03:23.099 --> 00:03:25.780 Exactly. And that number is generated by a very 00:03:25.780 --> 00:03:29.919 specific master formula. Criticality equals severity 00:03:29.919 --> 00:03:33.039 multiplied by likelihood multiplied by class. 00:03:33.400 --> 00:03:36.460 Severity times likelihood times class. Okay, 00:03:36.560 --> 00:03:39.259 when I first read this formula, it instantly 00:03:39.259 --> 00:03:41.680 reminded me of medical triage in an emergency 00:03:41.680 --> 00:03:43.639 room. Oh, that's a great way to look at it. Right. 00:03:43.919 --> 00:03:46.139 Imagine you are the triage nurse standing in 00:03:46.139 --> 00:03:48.599 front of a packed waiting room. You don't just 00:03:48.599 --> 00:03:50.419 treat the person who is crying the loudest. Because 00:03:50.419 --> 00:03:52.919 that might just be a stubbed toe. Exactly. And 00:03:52.919 --> 00:03:54.280 you don't just take people in the order they 00:03:54.280 --> 00:03:56.879 walk through the door. You evaluate three distinct 00:03:56.879 --> 00:04:00.419 things. First, what system is failing? Is it 00:04:00.419 --> 00:04:02.639 the heart or is it a scraped knee? That's the 00:04:02.639 --> 00:04:04.539 class. All right. Makes sense. Second, how badly 00:04:04.539 --> 00:04:06.800 is it failing? Is it a total arterial blockage 00:04:06.800 --> 00:04:09.080 or just a minor palpitation? That is the severity. 00:04:09.120 --> 00:04:11.680 Right. And third, how much of the body is affected? 00:04:11.900 --> 00:04:14.159 That is the likelihood. The ER analogy works 00:04:14.159 --> 00:04:17.839 beautifully, but with one major caveat that makes 00:04:17.839 --> 00:04:21.240 software triage even harder. In software, the 00:04:21.240 --> 00:04:24.100 patient is a million people at once. Oh, wow. 00:04:24.660 --> 00:04:26.839 Yeah, I guess that's true. You aren't just looking 00:04:26.839 --> 00:04:30.220 at one failing heart. You are looking at a million 00:04:30.220 --> 00:04:33.040 scraped knees simultaneously. That sounds like 00:04:33.040 --> 00:04:35.170 a nightmare. It is. And because human beings 00:04:35.170 --> 00:04:38.449 are incredibly visual creatures, a very common 00:04:38.449 --> 00:04:41.250 trap in problem solving is confusing how bad 00:04:41.250 --> 00:04:44.470 it looks with how critical it actually is. I 00:04:44.470 --> 00:04:46.629 do that all the time. We all do. You might have 00:04:46.629 --> 00:04:49.230 a massive garish error message that pops up on 00:04:49.230 --> 00:04:51.790 the screen, taking up the whole display. It looks 00:04:51.790 --> 00:04:53.829 terrifying to the user. Like the whole computer's 00:04:53.829 --> 00:04:56.689 melting down. Exactly. But technologically, it 00:04:56.689 --> 00:04:59.269 might only be affecting a tiny cosmetic teacher. 00:04:59.529 --> 00:05:01.870 While at the same time, a tiny line of invisible 00:05:01.870 --> 00:05:04.910 code is quietly calculating tax percentages wrong 00:05:04.910 --> 00:05:08.550 for every user in the database. Precisely. And 00:05:08.550 --> 00:05:11.430 if you don't forcibly separate class, severity, 00:05:11.810 --> 00:05:14.470 and likelihood, human nature guarantees you will 00:05:14.470 --> 00:05:17.250 panic over the ugly error message. And completely 00:05:17.250 --> 00:05:21.069 miss the silent data corruption. Exactly. This 00:05:21.069 --> 00:05:24.069 three -pronged mathematical approach forces the 00:05:24.069 --> 00:05:26.449 developer to decouple their visual -emotional 00:05:26.449 --> 00:05:28.970 reaction from the objective reality of the failure. 00:05:29.310 --> 00:05:32.189 OK, so relying on the causality of this framework, 00:05:32.610 --> 00:05:34.910 we have to start by defining the ecosystem of 00:05:34.910 --> 00:05:37.610 the failure itself. Right, the foundation. According 00:05:37.610 --> 00:05:40.709 to the source, you cannot even begin to score 00:05:40.709 --> 00:05:43.990 how bad an issue is until you define its fundamental 00:05:43.990 --> 00:05:47.610 context. Every single defect must first be assigned 00:05:47.610 --> 00:05:50.339 a class. Yeah. The class defines the domain of 00:05:50.339 --> 00:05:52.480 the defect. It answers the foundational question, 00:05:52.660 --> 00:05:55.079 what kind of issue is this? The framework breaks 00:05:55.079 --> 00:05:57.759 this down into distinct tiers, starting at zero, 00:05:58.019 --> 00:06:01.060 and class zero is reserved for critical system 00:06:01.060 --> 00:06:03.300 -level survival. Like the servers are on fire? 00:06:03.600 --> 00:06:05.720 Literally or metaphorically, yeah. This includes 00:06:05.720 --> 00:06:08.639 stability, reliability, availability, and security. 00:06:09.079 --> 00:06:11.579 It also covers storage, specifically preventing 00:06:11.579 --> 00:06:13.899 data loss or corruption. Here's where it gets 00:06:13.899 --> 00:06:16.000 really interesting, though, because the source 00:06:16.000 --> 00:06:18.699 states that Class Zero also includes legal issues. 00:06:18.699 --> 00:06:22.079 It does. Liability, ADA compliance for accessibility, 00:06:22.620 --> 00:06:25.360 and copyright infringement. Essentially lumps 00:06:25.360 --> 00:06:29.579 losing user data in with getting sued over a 00:06:29.579 --> 00:06:31.620 stolen image. Yep, they share the exact same 00:06:31.620 --> 00:06:34.339 rank. I have to admit, that threw me. I mean, 00:06:34.500 --> 00:06:36.680 why is a legal liability treated mathematically 00:06:36.680 --> 00:06:39.000 the same as a server literally catching on fire? 00:06:39.259 --> 00:06:42.040 That legal inclusion is usually what trips people 00:06:42.040 --> 00:06:44.399 up. But think about it from the perspective of 00:06:44.399 --> 00:06:47.019 the application's actual survival in the real 00:06:47.019 --> 00:06:50.660 world. OK. A bug isn't just bad code. It is a 00:06:50.660 --> 00:06:52.860 mechanism that interacts with society. Oh, I 00:06:52.860 --> 00:06:54.819 see what you mean. Right. If your software isn't 00:06:54.819 --> 00:06:57.339 Adyay compliant or you are accidentally displaying 00:06:57.339 --> 00:07:00.040 copyrighted material, a judge can issue an injunction 00:07:00.040 --> 00:07:02.180 that pulls your application offline completely. 00:07:02.459 --> 00:07:04.500 Oh, wow. So from the user's perspective, the 00:07:04.500 --> 00:07:06.480 app being legally banned from the App Store is 00:07:06.480 --> 00:07:08.259 functionally identical to the server's crashing. 00:07:08.459 --> 00:07:11.040 The result is exactly the same. The system ceases 00:07:11.040 --> 00:07:14.180 to exist. Therefore, it is a foundational class's 00:07:14.180 --> 00:07:16.699 existential threat. That is a massive perspective 00:07:16.699 --> 00:07:19.079 shift. It forces the engineer to step out of 00:07:19.079 --> 00:07:22.000 the code and look at the actual business consequences. 00:07:22.540 --> 00:07:25.180 Which engineers don't always naturally do. Right. 00:07:25.639 --> 00:07:28.899 OK, so class EO is life or death. Once you move 00:07:28.899 --> 00:07:32.720 past that, the framework essentially starts measuring 00:07:32.720 --> 00:07:34.759 different levels of friction. Exactly. Instead 00:07:34.759 --> 00:07:36.699 of reading down the entire list sequentially, 00:07:37.019 --> 00:07:39.399 let's look at how Classes 1, 2, and 3 behave. 00:07:39.699 --> 00:07:42.480 They cover everything from a sluggish loading 00:07:42.480 --> 00:07:45.240 screen, to a future doing the wrong math, to 00:07:45.240 --> 00:07:47.920 a frustrating user interface. The system isn't 00:07:47.920 --> 00:07:51.100 dying, but it is making the user's life progressively 00:07:51.100 --> 00:07:53.779 more difficult. And these middle tiers represent 00:07:53.779 --> 00:07:56.639 the bulk of everyday software issues. Oh, absolutely. 00:07:56.860 --> 00:07:59.420 Class 1 deals with performance. The software 00:07:59.420 --> 00:08:01.920 works, but it's hogging all your computer's memory. 00:08:02.040 --> 00:08:05.439 Classic. down to logical correctness. So the 00:08:05.439 --> 00:08:07.939 math is wrong or the system isn't talking to 00:08:07.939 --> 00:08:10.100 other software properly. Okay, got it. And then 00:08:10.100 --> 00:08:12.620 Class 3 drops further down to user experience 00:08:12.620 --> 00:08:15.600 and workflow. The menus are confusing or the 00:08:15.600 --> 00:08:17.500 documentation is poorly written. And notice how 00:08:17.500 --> 00:08:19.339 far away we are getting from actual systemic 00:08:19.339 --> 00:08:21.959 collapse. We're miles away from it. But a massive 00:08:21.959 --> 00:08:24.459 percentage of angry user complaints live right 00:08:24.459 --> 00:08:27.430 here in Class 3. Right, because they are frustrated 00:08:27.430 --> 00:08:29.569 because the workflow is clunky, but their actual 00:08:29.569 --> 00:08:32.370 data is perfectly safe. Exactly. Which brings 00:08:32.370 --> 00:08:34.970 us to the absolute bottom of the barrel, Class 00:08:34.970 --> 00:08:38.970 4. Presentation and cosmetic defects. Typographical 00:08:38.970 --> 00:08:41.850 errors, grammatical mistakes, aesthetics, or 00:08:41.850 --> 00:08:44.750 visual cosmetic issues. Basically, a typo is 00:08:44.750 --> 00:08:47.070 rock bottom. And that rock bottom ranking is 00:08:47.070 --> 00:08:50.750 completely intentional. But the source text lays 00:08:50.750 --> 00:08:53.549 out a crucial rule for how class interacts with 00:08:53.549 --> 00:08:55.669 everything else. And it is vital to understand. 00:08:55.809 --> 00:08:59.190 Later. The class provides the unbreakable context 00:08:59.190 --> 00:09:01.990 for evaluating the symptom. Meaning what exactly? 00:09:02.370 --> 00:09:05.620 Well, for example, a class is your issue. Let's 00:09:05.620 --> 00:09:08.200 say a critical stability flaw that only presents 00:09:08.200 --> 00:09:10.519 with a minor visual symptom must still be treated 00:09:10.519 --> 00:09:12.860 more seriously than a class 4 cosmetic issue 00:09:12.860 --> 00:09:14.919 with the exact same visual symptom. Can you give 00:09:14.919 --> 00:09:17.399 me a concrete example of how that plays out in 00:09:17.399 --> 00:09:19.860 reality? Sure. Imagine a user reports that a 00:09:19.860 --> 00:09:22.220 specific button on the dashboard flickers for 00:09:22.220 --> 00:09:24.600 half a second when they log in. Okay. Visually, 00:09:24.820 --> 00:09:28.360 it is just a flicker. Right. Now, if the developers 00:09:28.360 --> 00:09:31.620 investigate and realize that Flickr is caused 00:09:31.620 --> 00:09:36.120 by a simple CSS coding typo, it is a class four 00:09:36.120 --> 00:09:38.919 aesthetic bug. It is a super low priority. Makes 00:09:38.919 --> 00:09:42.080 sense. But what if they investigate and realize 00:09:42.080 --> 00:09:44.399 that the flicker is happening because the backend 00:09:44.399 --> 00:09:46.960 server is quietly rebooting itself and nearly 00:09:46.960 --> 00:09:49.700 crashing every time someone logs in? Oh, wow. 00:09:49.759 --> 00:09:52.620 And the flicker is just the visual artifact of 00:09:52.620 --> 00:09:54.779 that near collapse. And the symptom is identical, 00:09:54.840 --> 00:09:57.240 but the disease is entirely different. Exactly. 00:09:57.279 --> 00:10:00.039 You do not treat the symptom, you treat the underlying 00:10:00.039 --> 00:10:03.000 class of the disease. So the framework forces 00:10:03.000 --> 00:10:05.519 developers to investigate the root cause rather 00:10:05.519 --> 00:10:08.299 than just slapping a visual bandaid on a flickering 00:10:08.299 --> 00:10:11.200 button and Exactly. It prevents lazy debugging. 00:10:11.799 --> 00:10:14.120 But knowing that a bug is a fundamental security 00:10:14.120 --> 00:10:16.480 flaw doesn't necessarily tell the developers 00:10:16.480 --> 00:10:19.220 how much it is actually hurting the user right 00:10:19.220 --> 00:10:21.539 now, in this given moment. No, it doesn't. That 00:10:21.539 --> 00:10:23.559 requires a totally different metric, which brings 00:10:23.559 --> 00:10:25.960 us to the second piece of the formula. Severity. 00:10:26.159 --> 00:10:28.679 Right. Severity measures the degree to which 00:10:28.679 --> 00:10:32.139 the defect affects the users or the system operation. 00:10:32.480 --> 00:10:34.960 And the way this scale is structured is totally 00:10:34.960 --> 00:10:37.320 fascinating to me. It's entirely built around 00:10:37.320 --> 00:10:39.519 the concept of the workaround. It really is. 00:10:39.779 --> 00:10:42.679 A severity zero means the defect affects critical 00:10:42.679 --> 00:10:45.799 data or functionality and leaves the user with 00:10:45.799 --> 00:10:48.240 absolutely no workaround. They're dead in the 00:10:48.240 --> 00:10:50.639 water. Totally paralyzed. They cannot do their 00:10:50.639 --> 00:10:53.600 job. But the moment a workaround exists, the 00:10:53.600 --> 00:10:57.409 severity drops. A severity 1 still affects critical 00:10:57.409 --> 00:11:00.320 functionality. but it forces the user to employ 00:11:00.320 --> 00:11:02.220 a workaround. Right. They can still barely get 00:11:02.220 --> 00:11:04.919 by. And the middle tiers, severity two and three, 00:11:05.200 --> 00:11:07.679 they also heavily factor in whether a workaround 00:11:07.679 --> 00:11:11.000 is forced or available for non -critical functions. 00:11:11.179 --> 00:11:14.000 And finally, severity four purely affects aesthetics 00:11:14.000 --> 00:11:16.820 and doesn't hinder functionality at all. I have 00:11:16.820 --> 00:11:18.759 to push back on this reliance on the workaround, 00:11:18.940 --> 00:11:21.779 though. Oh, how so? Well, isn't a broken feature 00:11:21.779 --> 00:11:24.059 still fundamentally broken? I mean, if I buy 00:11:24.059 --> 00:11:26.279 a brand new car and the driver's side door is 00:11:26.279 --> 00:11:28.559 jammed shut, but I can technically climb in through 00:11:28.559 --> 00:11:30.840 the passenger side, the car is still broken. 00:11:31.100 --> 00:11:33.980 That is a very fair point. Right. Why does the 00:11:33.980 --> 00:11:36.919 mere existence of a workaround change the mathematical 00:11:36.919 --> 00:11:40.179 severity score so drastically that it drops it 00:11:40.179 --> 00:11:43.279 out of the highest emergency tier? Well, if we 00:11:43.279 --> 00:11:45.419 connect this to the bigger picture, it reveals 00:11:45.419 --> 00:11:49.220 the true pragmatic philosophy behind this entire 00:11:49.220 --> 00:11:52.039 metric. Which is? The framework acknowledges 00:11:52.039 --> 00:11:55.500 a harsh reality. Engineering resources are finite. 00:11:55.799 --> 00:11:59.039 Ah. You simply cannot fix everything at once. 00:11:59.220 --> 00:12:01.100 You can't. You have a limited number of developers 00:12:01.100 --> 00:12:04.299 and a limited number of hours. So the inclusion 00:12:04.299 --> 00:12:07.159 of the workaround acts as a vital pressure valve 00:12:07.159 --> 00:12:09.460 for the team. So it's not about whether the user 00:12:09.460 --> 00:12:11.899 is annoyed. It's about whether they are completely 00:12:11.899 --> 00:12:14.620 paralyzed. Exactly. If the office worker can 00:12:14.620 --> 00:12:17.970 still export their broken data to Excel... fix 00:12:17.970 --> 00:12:20.470 it manually, and re -import it to get their report 00:12:20.470 --> 00:12:22.450 done, they are going to be miserable. They're 00:12:22.450 --> 00:12:23.929 essentially climbing through the passenger door 00:12:23.929 --> 00:12:26.549 of the car. Perfectly said. But they are not 00:12:26.549 --> 00:12:29.129 entirely blocked from operating. That workaround, 00:12:29.509 --> 00:12:32.129 as exhausting as it is for the user, buys the 00:12:32.129 --> 00:12:34.129 developers the one thing they need most during 00:12:34.129 --> 00:12:39.509 a crisis. Yes. Time. It drops a severity zero 00:12:39.509 --> 00:12:42.649 down to a severity one. It acknowledges the human 00:12:42.649 --> 00:12:45.330 reality of using the system and prioritizes the 00:12:45.330 --> 00:12:47.909 people who are truly dead in the water over the 00:12:47.909 --> 00:12:50.309 people who are merely severely inconvenienced. 00:12:50.429 --> 00:12:53.330 That is incredibly pragmatic. It is triage in 00:12:53.330 --> 00:12:56.250 its purest form. Right. Okay. So we have the 00:12:56.250 --> 00:12:58.350 class, which tells us what is broken. Right. 00:12:58.389 --> 00:13:00.649 We have the severity, which tells us how badly 00:13:00.649 --> 00:13:03.169 it is disrupting the workflow. Now we need the 00:13:03.169 --> 00:13:05.919 final piece of the formula. Likelihood Crowd 00:13:05.919 --> 00:13:08.740 Exactly. How many people are actually experiencing 00:13:08.740 --> 00:13:11.100 this pain? The likelihood measures visibility. 00:13:11.389 --> 00:13:13.649 And instead of reciting the specific percentage 00:13:13.649 --> 00:13:16.370 brackets, the core concept is understanding the 00:13:16.370 --> 00:13:18.950 scale of exposure. A likelihood of one means 00:13:18.950 --> 00:13:21.389 the defect is highly visible, encountered by 00:13:21.389 --> 00:13:24.169 95 % or more of the user base. It's front and 00:13:24.169 --> 00:13:26.549 center. Everyone sees it. Right. On the opposite 00:13:26.549 --> 00:13:28.690 end, a likelihood of four means it is buried. 00:13:29.129 --> 00:13:31.789 It is seen by fewer than a third of users, perhaps 00:13:31.789 --> 00:13:34.529 hidden deep in a rarely used settings menu. But 00:13:34.529 --> 00:13:36.850 wait, why is likelihood treated as a separate 00:13:36.850 --> 00:13:39.789 multiplier at the end? If a huge volume of users 00:13:39.789 --> 00:13:42.669 are screaming about an issue, doesn't that inherently 00:13:42.669 --> 00:13:45.389 make it a severe problem that should be prioritized? 00:13:45.629 --> 00:13:47.870 Well, this is where the framework protects developers 00:13:47.870 --> 00:13:50.610 from the vocal minority, particularly in the 00:13:50.610 --> 00:13:53.190 age of social media. Oh, that makes sense. Right. 00:13:53.789 --> 00:13:56.970 A thousand angry users posting online feels like 00:13:56.970 --> 00:13:59.470 a massive system -wide failure. It feels like 00:13:59.470 --> 00:14:01.350 a likelihood of one. It feels like everyone. 00:14:01.500 --> 00:14:04.919 But if your software has 10 million active users, 00:14:05.500 --> 00:14:08.159 those thousand angry voices represent a fraction 00:14:08.159 --> 00:14:10.299 of a percent of your user base. It is actually 00:14:10.299 --> 00:14:12.659 a likelihood of four. That's a huge difference. 00:14:12.740 --> 00:14:15.360 It is. By forcing the developer to calculate 00:14:15.360 --> 00:14:18.240 the actual mathematical percentage of users affected, 00:14:18.700 --> 00:14:21.299 it strips away the psychological pressure of 00:14:21.299 --> 00:14:23.960 the loud crowd. It forces you to look at the 00:14:23.960 --> 00:14:26.500 silent majority. So what does this all mean when 00:14:26.500 --> 00:14:28.360 we put the pieces together? We have our three 00:14:28.360 --> 00:14:31.659 numbers. Class. severity, and likelihood. And 00:14:31.659 --> 00:14:34.000 the formula dictates that we multiply them together 00:14:34.000 --> 00:14:36.299 to get our ultimate defect criticality score. 00:14:36.740 --> 00:14:40.340 Right. The exact ranges of the resulting matrix 00:14:40.340 --> 00:14:42.779 don't matter as much as how the math manipulates 00:14:42.779 --> 00:14:45.720 the extremes. Let's look at the cosmetic typo 00:14:45.720 --> 00:14:48.919 on a rarely used screen. OK. A typo is cosmetic, 00:14:49.299 --> 00:14:51.879 making it a class 4. Yep. It's a minor aesthetic 00:14:51.879 --> 00:14:54.740 issue, so it's a severity 4. And it's on a rarely 00:14:54.740 --> 00:14:57.149 used screen, giving it a likelihood of 4. So 00:14:57.149 --> 00:15:00.009 you multiply 4 times 4 times 4, and the formula 00:15:00.009 --> 00:15:03.110 multiplies out to 64. Which mathematically banishes 00:15:03.110 --> 00:15:05.529 it to the very bottom tier of the priority list. 00:15:05.629 --> 00:15:08.070 It becomes a low criticality defect. And that 00:15:08.070 --> 00:15:10.730 mathematical banishment is so necessary because 00:15:10.730 --> 00:15:13.429 human nature dictates that developers will actually 00:15:13.429 --> 00:15:15.429 want to fix that typo first. Oh, absolutely. 00:15:15.590 --> 00:15:18.399 It is the trap of the quick win. Right. Fixing 00:15:18.399 --> 00:15:20.519 a typo takes 30 seconds. It gives the developer 00:15:20.519 --> 00:15:22.679 a quick dopamine hit of accomplishment. They 00:15:22.679 --> 00:15:25.080 can close a ticket and feel productive. But spending 00:15:25.080 --> 00:15:28.000 time fixing a typo while a complex, difficult 00:15:28.000 --> 00:15:30.919 database error sits untouched is terrible resource 00:15:30.919 --> 00:15:34.000 management. The math forces the score so high 00:15:34.000 --> 00:15:36.639 that the developer is essentially forbidden from 00:15:36.639 --> 00:15:39.240 prioritizing the easy work over the important 00:15:39.240 --> 00:15:42.159 work. I love that. But the true brilliance of 00:15:42.159 --> 00:15:45.139 this formula lies in a specific mathematical 00:15:45.139 --> 00:15:47.740 quirk at the other end of the spectrum. Oh, the 00:15:47.740 --> 00:15:50.899 zero multiplier. Yes, because the formula relies 00:15:50.899 --> 00:15:54.919 entirely on multiplication. Any zero in the equation 00:15:54.919 --> 00:15:57.620 acts as an absolute override. Because if you 00:15:57.620 --> 00:16:00.179 multiply anything by zero, the result is zero. 00:16:00.379 --> 00:16:03.080 Exactly. So if an issue is a class zero data 00:16:03.080 --> 00:16:05.879 thread or a severity zero blockage, the final 00:16:05.879 --> 00:16:08.519 criticality score automatically becomes zero. 00:16:08.700 --> 00:16:10.940 And this raises an important question about how 00:16:10.940 --> 00:16:13.379 we design systems to protect their core functions 00:16:13.379 --> 00:16:16.679 against human bias. How so? Well, this mathematical 00:16:16.679 --> 00:16:19.820 quirk is not a mistake. It is an automatic, non 00:16:19.820 --> 00:16:22.299 -negotiable circuit breaker. OK, give me an example. 00:16:22.679 --> 00:16:25.240 Let's say you discover a class zero defect, a 00:16:25.240 --> 00:16:27.840 massive security hole that exposes user passwords. 00:16:27.879 --> 00:16:30.679 Horrifying. But it is buried so deep in legacy 00:16:30.679 --> 00:16:33.200 code that only one single user out of a million 00:16:33.200 --> 00:16:35.700 will ever accidentally trigger it. That is a 00:16:35.700 --> 00:16:38.419 likelihood of four. Extremely rare. But because 00:16:38.419 --> 00:16:40.519 it's a class zero, the math is zero multiplied 00:16:40.519 --> 00:16:43.320 by four. The result is zero. Exactly. It forces 00:16:43.320 --> 00:16:46.320 the final score into the top tier critical category. 00:16:46.679 --> 00:16:49.659 So the math demands that it be treated as an 00:16:49.659 --> 00:16:51.940 absolute emergency, regardless of how few people 00:16:51.940 --> 00:16:54.379 are actually experiencing it. It physically prevents 00:16:54.379 --> 00:16:57.220 the developers from saying, well, hardly anyone 00:16:57.220 --> 00:16:59.799 uses that feature, so let's just ignore the security 00:16:59.799 --> 00:17:02.600 leak. Wow. It prevents the crowd from dictating 00:17:02.600 --> 00:17:05.099 the safety of the system. It brings us right 00:17:05.099 --> 00:17:08.039 back to that emergency room analogy. The triage 00:17:08.039 --> 00:17:11.079 nurse isn't fooled if a patient having a massive 00:17:11.079 --> 00:17:13.720 internal hemorrhage happens to be sitting quietly 00:17:13.720 --> 00:17:15.839 in the corner. Invisible to the rest of the room. 00:17:15.900 --> 00:17:18.859 Right. invisible while 50 other people in the 00:17:18.859 --> 00:17:20.819 waiting room are loudly complaining about sore 00:17:20.819 --> 00:17:24.960 throats. The formula acts as the ultimate objective 00:17:24.960 --> 00:17:28.039 triage nurse. It really does. It identifies the 00:17:28.039 --> 00:17:31.420 silent but deadly systemic failures and pushes 00:17:31.420 --> 00:17:33.480 them straight to the operating table completely 00:17:33.480 --> 00:17:35.680 overriding the noise around them. And conversely 00:17:35.680 --> 00:17:38.000 it stops you from rushing a patient into emergency 00:17:38.000 --> 00:17:41.690 surgery just because they have a very loud, very 00:17:41.690 --> 00:17:44.089 visually disturbing, but ultimately completely 00:17:44.089 --> 00:17:47.069 harmless cosmetic rash. It forces you to allocate 00:17:47.069 --> 00:17:49.809 your limited energy entirely toward what sustains 00:17:49.809 --> 00:17:52.049 the life of the system, which is exactly why 00:17:52.049 --> 00:17:55.250 this deep dive is so valuable. We took a seemingly 00:17:55.250 --> 00:17:58.789 dry, ironically flawed Wikipedia article about 00:17:58.789 --> 00:18:01.809 software testing and uncovered a total master 00:18:01.809 --> 00:18:05.430 class in decision making. It's surprisingly universal. 00:18:05.630 --> 00:18:08.269 It is. You can take this exact formula class, 00:18:08.549 --> 00:18:11.569 severity, likelihood, and apply it to your own 00:18:11.569 --> 00:18:14.269 life the second this audio finishes. Totally. 00:18:14.569 --> 00:18:17.250 When you look at your overwhelming email inbox 00:18:17.250 --> 00:18:20.269 or your massive to -do list or a complex challenge 00:18:20.269 --> 00:18:22.509 at work, you don't have to feel paralyzed by 00:18:22.509 --> 00:18:24.589 the sheer volume of demands. You don't have to 00:18:24.589 --> 00:18:27.029 just react to whichever client or problem is 00:18:27.029 --> 00:18:29.670 yelling the loudest. You can stop, assign a class 00:18:29.670 --> 00:18:32.190 to understand the domain, rate the severity based 00:18:32.190 --> 00:18:34.670 on actual blockage, calculate the likelihood 00:18:34.670 --> 00:18:37.210 of impact, and let the objective math do the 00:18:37.210 --> 00:18:39.769 heavy lifting for you. It is an incredibly powerful 00:18:39.769 --> 00:18:42.589 tool for reclaiming your clarity. But before 00:18:42.589 --> 00:18:44.250 we wrap up today, I want to leave you with one 00:18:44.250 --> 00:18:46.289 final thought to mull over as you apply this 00:18:46.289 --> 00:18:48.809 framework to your own world. Go for it. We talked 00:18:48.809 --> 00:18:51.769 at length about how a workaround drops the severity 00:18:51.769 --> 00:18:54.569 of a problem. It buys developers time, but it 00:18:54.569 --> 00:18:57.450 leaves the underlying issue completely unresolved. 00:18:57.450 --> 00:19:01.259 Right. If you applied this exact defect criticality 00:19:01.259 --> 00:19:03.579 formula to the everyday frictions, stresses, 00:19:03.920 --> 00:19:06.619 and systemic problems in your own life, what 00:19:06.619 --> 00:19:08.940 silent class zero issues have you been completely 00:19:08.940 --> 00:19:11.339 ignoring simply because you managed to find an 00:19:11.339 --> 00:19:13.960 exhausting temporary workaround? Wow. That is 00:19:13.960 --> 00:19:15.660 something to think about. Until next time, keep 00:19:15.660 --> 00:19:16.200 digging deeper.