What's good, George Burroughs back again with another video. So we're going to check out 20 funny times. WWE wrestlers broke the fourth wall. Now, the wrestlers are not supposed to be breaking the fourth wall, just like in a lot of media, you know, certain things are not supposed to be, you know, the fourth wall is not supposed to be broken. But sometimes it does happen. It depends on the wrestler, depends on the character. And it can, a lot of times it's actually pretty funny. So we're going to check out some of these moments where wrestlers are, you know, decided to break the fourth wall. And it should be a good one, man. This would be this video brought to you by tap out corner once again. Subscribe to him if you haven't already. Let's check this out, man. Whenever a wrestler is doing an interview backstage, there's one thing you'll never see, and that's the interviewer's feet. There's a good explanation and I'll let Triple H show you why.  I don't have an answer for that. John Cena breaks the fourth wall like nobody. That's funny, bro. Why would they break the fourth wall on that? It's probably to make the like the announcers shorter or the not announcers, but the person's doing the interview shorter. Because normally they're probably wearing heels. So you probably want to make them shorter than whoever they're interviewing. But he yells, as you will see throughout this video, when the leader of the C nation returned in 2003, he got a visit from Austin Theory. Cena rose to the United States champion so hard that he broke the fourth wall. You know what?  I would so much rather be bald than have them pipe in fake crowd noise for my matches because nobody cares. Once he said that, I was like, yeah, bro, yeah, he's yeah, man. He's already cut John. Stop it. Just now you're over cooking up in case you're wondering. Yes, WWE actually does play crowd sound effects during matches. One thing that every wrestling fan knows is that in WWE, there are cameras everywhere. Sometimes there's a logical explanation for why a camera catches a backstage instant like when a wrestler is getting interviewed. However, most of the time, wrestlers and fans are supposed to pretend that like there isn't a camera following the wrestlers around. However, during Dean Ambrose's phase as an interviewer, he made a funny joke about this weird part of WWE. Well, there's cameras in here. It'd be kind of weird if there were cameras in the locker room if we didn't have an interview. Yeah, it would be weird if there were cameras in the locker room. On SmackDown in 2022, a six-pack challenge was set up with the winner facing the SmackDown Women's Champion, Ronda Rousey at Money in the Bank. Aliyah was one of the participants, but she didn't come out when her music played. As it turned out, Shotzi had locked Aliyah in the locker room as well as someone else. Shotzi locks Aliyah and a camera operator in the women's. Man, we miss you, Pat McAfee, man. I miss you on commentary. That's funny, bro. The camera guy got locked in, too. He didn't do nothing. They could have shot that differently where the camera guy is outside the room. You have people running in trying to break open the door or something. I don't know. The biggest unanswered question in WWE history is who threw the pie at Kevin Owens? WWE later did an interview with KO. And while Owens didn't have an answer, he still managed to break the fourth wall. WWE had this amazing technology on Monday night where you guys could actually see through my eyes what was happening. So everybody knows that when I turned, all I saw was a pie coming at me. This is why I love Kevin. He said WWE has this amazing technology where you can see. But it did look so hokey. He didn't even have to do that. You could have just had a shot of someone throwing a pie at him off camera. But instead, you switch to him looking at a pie coming to him.  Don't you remember that when you saw through my eyes on the final row? That was great.  This is nothing new. And John Cena actually pointed this out. You guys ever noticed that every time somebody comes down that ramp for Monday Night Raw, they just get a microphone and talk about what happened last week. You know what? Tonight, I am going to do the exact same thing. Oh, come on, Sina. I think that's only happened on every single episode of Raw. Here's one thing that doesn't make any sense. When a champion issues an open challenge, why does only one wrestler answer? It's a free championship match. So every wrestler want to accept it. Well, in 2023, we finally saw what goes on backstage when an open challenge is issued on NXT. The North American champion, Wesley, had issued an open challenge. The cameras went backstage to reveal a ton of wrestlers all scrambling to try and be the first person in the ring. So that's what was really going on when John Cena. Yeah, that's exactly what's going on. They just pranked in the back. No, I want a title opportunity. No, I want the title opportunity. This weekly open challenge in 2015. Oh, my gosh. SmackDown was on a Tuesday. Yes, before the blue show aired live on Friday nights, SmackDown used to be filmed on Tuesdays and would air a few days later. For example, when Dean Ambrose kicked off the June 11th, 2015 episode of SmackDown, it was broadcast on a Thursday. However, it was all filmed on Tuesday. Ambrose had Seth Rollins, WWE World Heavyweight Championship, but Rollins came out to reclaim his title. Dean then revealed it was a replica he bought at the merch table and then said this. Truth be told, I don't remember exactly where I left the real championship. The last few days have been a bit of a blur and they all rolled into one. I mean, it still feels like it's Tuesday to me today. I guess it felt like a Tuesday because it was. It's always cool when from out of nowhere, a wrestler's theme song starts playing and they run into the ring to make a big save. However, it was never explained how the WWE production crew is able to hit the music right before the wrestler runs out. Well, until the 16th, we finally found out how they do it. Seth Rollins is looking for his SummerSlam opponent, Finn Balor. The Raw General Manager, Mick Foley, suggested Seth try calling out Finn from the ring. Seth agreed and headed out to the arena. Someone had to tell the production crew to play Seth's music and this happened. Hey, this is Raw General Manager, Mick Foley. Will you hit Seth Rollins' music please? It's not uncommon for a manager or someone else to get banned from ringside as part of a WWE storyline. However, the person who gets banned always seems to still show up and interfere in the match. Well, finally, SmackDown General Manager Daniel Bryan decided to address this. I don't know why this happened. Every time we banned somebody from ringside or we banned somebody from the arena, they always show up. Can we not afford good security? There needs to be. We are a building dollar company. For example, a fan who doesn't have a ticket can't get in. But look, I mean, when your face is kind of your security badge to get into the building, even when you're James Ellsworth, you're going to get in. Maybe all the security is just not being alerted to this. I don't know. I think we do a fairly good job of alerting people either that or we need better alerters. We need better alerters and we need better security. More alerters. We've got to get on this. But either way, if you see something, say something. Here's how you win the World Rumble. Don't get eliminated and try to eliminate as many other competitors as possible. It would make sense then if you see one wrestler trying to eliminate another that you should work together and get that person eliminated to better your odds of winning. Despite this, in every single rumble match, wrestlers will save someone from being eliminated by attacking the person who is doing the elimination. I always noticed that even as a kid, I was like, wait a minute. Why wouldn't he just let him eliminate him? It makes his odds better. Hell, work together, get him out. You know, it makes it just makes so much sense to do it that way. But, you know, you know. It doesn't make any sense, but fans suspend their disbelief. However, during the Chills in 23 World Rumble, commentator Corey Graves finally snapped. I'm gonna vent for a second. What we just saw happens in every rumble match and it drives me up a wall. If somebody's in the process of getting eliminated, why would you go and try to eliminate the person who's trying to eliminate the other person?  I'm glad to hear your record, right? No, it's about WrestleMania. After training facing Chills in 3 and becoming a good guy, fans have been demanding that John Cena turn heel and become a villain again. Well, the night after WrestleMania 29, Cena gave the people what they wanted. Literally. No, I got it, I got it. A heel turn. That's the closest we ever got to seeing John Cena turn heel again. Yeah. The Undertaker normally wasn't one to break the fourth wall, given his character, but he did do it once. During a backstage interview, the dead man said this. Well, listen to this, Rock.  Undertaker was not lying. The Rock, like all WWE wrestlers, had writers come up with the stuff he said on the mic. Here's a little different secret. Whenever they need people to- It's very rare to see, you know, the Undertaker kind of break the fourth wall. He was always a stoic, serious character. Even when he had the American Badass gimmick. You know, he was serious. It was hard to, you know, kind of break his character, like, try to get him to crack. It was very hard to do that. So for him to even say that, that's pretty cool, man. To play security guards, medical staff, Adam Rose's rose buds, or stuff like that, WWE usually gets local wrestlers who haven't been on TV to play those parts. You'll even sometimes see the same person playing completely different roles. On Raw in 2014, Dean Ambrose got confronted by a group of security guards and made this comment. Are you guys real security? So I could have sworn you rose buds last week. The contract signing is one of the most iconic WWE moments. This helps add drama and tension to any match, which is why we've seen it so many times. Of course, since it is wrestling, it's tradition that the two wrestlers end their contract signing by fighting. In 2011, John Cena and CM Punk were doing a contract signing for their match at SummerSlam and the best in the world made this comment. I mean, when's the last time we had one of these contract signings that didn't end in some sort of horrible physical calamity? Yeah, flip the table over and we can all start beating each other up. I'm happy to say the table did eventually get flipped over. Later, we got another contract signing. This time between Seth Rollins, Randy Orton, Roman Reigns and Dean Ambrose. All of a sudden, Ambrose got up and started moving the table and said this. We all know how this is going to end anyway. I called Tim's on the table. That was when he was like, we know how this is going to end. I called Tim's on the table. Ross started with Ric Flair, Triple H and Shawn Michaels, taking on all five members of the Spirit Squad. Despite the disadvantage, the game, HBK and The Nature Boy were able to defeat a group of male cheerleaders. Afterward, Triple H and Michaels threw the Spirit Squad into a box that was being sent to OVW in Louisville, Kentucky. I remember that, but I shipped these things out, get them out of here. OVW stood for Ohio Valley Wrestling and was WWE's development system at that time. In real life, all the Spirit Squad members were going back to OVW for more training, so seeing Triple H and HBK do this was very meta. Okay, this was both Ric from TNA or Impact Wrestling, but it's too funny not to include. So for a little while, whenever they showed a backstage segment on Impact, it was always filmed like the cameraman was hiding. They explained our wrestlers would talk openly because they didn't think anyone was there. Well, except for one incident. It's two of us against one of you. You know what? The only witness this is, is the cameraman.  It's the government way. You talking about me? That is funny, bro. I hope she's not talking about me, man. How can she see me? On SmackDown, the man rose a city in the ring when Kevin Owens interrupted. KO tried to pull a fast one on Dean, but in the lead-up to their match at No Mercy, John Cena and R- I didn't do that, y'all. They probably had to cut it out. Maybe copyright reasons. You know, sometimes WWE, you know, they can be strict on it. So they cut it out. So I'm guessing that's what it was. Roman Reigns, King- It's called a promo.  Hey, they cut that too. You're gonna have to learn how to do it. So go ahead. See you fourth wall. Just like other people on TV, WWE wrestlers will sometimes write notes on their wrists, so they remember what to say. When the Rock returned to WWE in 2012, he spent a lot of time talking in the ring, usually about his WrestleMania opponent, John Cena. During one episode of Raw, the camera caught notes right on the Great One's arm. John Cena later came out to confront the Rock. Cena said some pretty standard things about his opponent, but then he added this. I don't need words like respect and loyalty to Trent worldwide, just like I don't need my notes for my promo and my wrist. Some people say that- And this was, yeah, the Rock was legit pissed, bro. Because he crossed that line. That was like, okay, that wasn't part of the script. You really went behind my back on that one. Because he had to, and it was crazy because people didn't really realize it until it really got shown that that's what it was. And that's what kind of helped him, in a sense, kind of get a little bit of an upper hand against the Rock, because it's the Rock and John Cena.  So the Rock is automatically going to be a fan favorite going into any situation with a lot of people outside of a notable few like Stone Cold. You know what I'm saying? He would have a little back and forth there because of their rivalry or whatnot. So when John Cena is stepping up to this huge task of trying to hang with the Rock or even outperform him on a promo and he's able to get that little bit of dirt on him, he has to use it. I'm sure the Rock didn't like it, but that's the only way to kind of save himself from pretty much being overshadowed this whole little saga they was having. So I understand why he did it. I understand why the Rock was mad, but it made for great television. The Rock writing notes on his wrist was fake and it was just the of John Cena, something to roast the Rock with. However, that does not explain why. And, you know, he could he could say that he can say that. But I think we've seen the documentary where and I don't know how true it is, but John did say after that, like when they were talking at the end of that segment, they were talking the Rock was talking mad, mad shit, bro. He was like, he was really upset. Like that wasn't a joke.  So if you man did the same thing, find out what I'm talking about by hitting the video on screen. Yeah, man. So obviously this is one of those type of bids, man. I love seeing these type of videos going back and seeing wrestlers and breaking the fourth wall. It doesn't happen all the time. But when it does, man, it's quite hilarious for the most part. Comment down below. Let me know what's your favorite fourth wall break from a wrestler. It doesn't even have to be from this video. If you can remember a time where a wrestler broke the fourth wall, and it was just hilarious to you, comment down below. Let me know. But I appreciate all of the support you guys have shown on channel Road to 150K. And I am still the N speedy YouTube wrestling champion. We appreciate y'all kicking me. See y'all next one. Peace.


To me it also feels like a throwback to my beginnings. The fact is that 40 years ago, almost to the day, René Tom, the late René Tom and Ivan Kupka, who is very much alive over close to 90, invited me to this place to hold forth about resurgence and related topics. The two gentlemen were kind enough to severe it in my lucubrations and even offered practical support for René Tom offered to get my things typed by the secretary here at the institute. There was even Denis Sullivan on that day in the room. He showed his appreciation in his own way by reclining on the floor full length, but with eyes wide open, mind you, so that he could follow my scribblings on the blackboard at an angle. So nice to be here and nice to reconnect with these memories of long ago. Before starting, for good, let us get a few reminders quickly out of the way. Research and functions, of course, live in three models, in the formal model as formal power series or more general things, trains series, a mixture of power series of powers of z and exponentials of towers of exponentials. And then with the convolution model, with the operation being path convolution. And then in the geometric model, as sectorial germs at the infinite. So we start from the formal model, we want to get to the geometric model, but all the work and all the difficulty manifest in the intermediate model in the convolutive model. So the singularities in the convolutive model are responsible for the divergence and more or less they carry important information because they carry the Stokes constants. So it is important to measure them precisely. And the tool for doing that is the so-called alien derivations, which are the hallmark of resurgent functions, actually resurgent functions or functions which can submit to alien differentiation. The, the alien, they have indexes, indices, omega, which can, which belong to C or actually the C, the ramified version of C. And the, by definition, the alien derivation of a delta sub omega applied to phi of zeta is a weighted superposition of various determinations over zeta plus omega. This is defined with our difficulty close to the origin and then we move, it is extended. Thank you. I'll use that. This is extended in the large, by analytic continuation. So they are defined like everything else in the convolutive model, but by pull back the, extend to the multiplicative models. And in those two models, we have the additional invariant alien derivations denoted by this, by the double-struck delta. They're defined as the usual alien derivations with in front of them, sorry, an exponential factor. Then those invariant alien derivations commute with ordinary differentiation relative to z, which is very useful. So and of course they have no equivalent in the, in the convolutive model. So the most two important notions, objects, that can be attached to a given resurgent function are the active alien algebra and the display. Take a resurgent function or an algebra of such functions. Then take the completion of that with respect to alien and ordinary differentiation. Then take the ideal of all alien derivations that kill that completion, that completed algebra. This is a bilateral ideal. And then take the coefficient of all alien derivations by this ideal. This by definition, this object might actually reflect the concrete mode of action of alien derivations on that algebra. So to that extent it is essential. And the thing is that although by themselves on their own, alien derivations are totally free, totally unconstrained in concrete situations, they are anything but free. They are, most of the time, they actually turn out to be equivalent to be isomorphic to algebra, algebras of ordinary differential operators. So we'll see many instances of that. And then there is a display. It is a sort, as you can see on the formula, it is a sort of alien tail formula. But the main property and the main use is actually that of extending any relation between any number of resurgent functions. Take any relation r involving the plus, minus, composition, ordinary derivation, et cetera. And it automatically carries over to the displays, which is extremely useful because this second identity involves a huge number of constraints. So it is extremely useful to prove independent theorems and that sort of things. So now let us start in earnest for orientation and for perspective. Let us comment on, let us examine on a double column the main similarities and differences between equational resurgence and co-equational resurgence. This is going to be our main topic today, especially the second column. Equational resurgence is relative to a critical variable, the variable of an equation. Co-equational resurgence is relative to a critical parameter. In both cases, the activity in algebras are isomorphic, as I said, to algebras of ordinary differential operators. But in the second case, for co-equational resurgence, this algebra actually splits into two parts. Correspondingly, for equational resurgence, there is one set, one system of allium different equations that describe the whole situation, one bridge equation. For co-equational resurgence, there are two of them, two systems and very different ones. Then for co-equational resurgence, we have a real Stokes constant that can assume any complex values and they are usually transcendental. With co-equational resurgence, this is perhaps the main surprise, the main difference. Instead of that, we get discrete Stokes constants, which we call as a very specific object. They assume only after renormalization, there will be integers, we call them the tessellation coefficients. Then equation resurgence, as I said, all the work, all the proving has to be done in the convolution model. But with equation resurgence, convolution is ordinary convolution. For co-equational resurgence, it is not a binary operation, but a multiple convolution and a weighted one. There are weights attached to it and it is a much more, quite different operation. And then, as I said, with equation resurgence, the differential operators, which are equivalent to which the active value in algebra is isomorphic, they can be anything, they are not constrained. With co-equational resurgence, they are heavily constrained. They verify, they kill a certain two-form, which we call the isographic form. And then, with equation resurgence, the sums in the geometric models are ramified at infinity. In the, with co-equational resurgence, they are either not ramified at all or finitely ramified. And so the, the, the exhibit, this very unusual combination of divergence, of being resurgence in various sectors, and being an entire function. We call them, and there's more to that, we call them attack function. And then the last event, of course, with co-equational resurgence, everything is ten times simpler and more straightforward than with co-equational resurgence. Okay, so let's go. So very briefly, and let us review, equation resurgence, not for its own sake, but as a counterpoint to what is, to co-equational resurgence. Make any equation differential, non-linear, differential difference, composition equation, or general functional equation, and then form its full, its full solution with a maximum number of parameters in it. Then the rule of thumb, you can say that the existence side by side in this equation of powers, inverse powers, z, and exponentials, either of z of powers, z points to the existence of resurgence. Actually, there will be as many critical times as there exist blocks, and let us say, powers inside the exponentials. Mercifully, in most situations, there is only one critical time, but if there are more than one, then we can live with that. There is an apparatus to deal with that, simply there are many, we have to consider to go through many boreal planes, and we first to classify the critical times from slower to faster, and then we go through the boreal planes by means of operators, which resemble Laplace operators but with a different and more sophisticated kernel. So, and then there is a few, once we've got hold of the formal solution, there is a purely formal, there are purely formal manipulations, which tell you which alien derivations are going to act effectively on that, and for forming the homogeneous, differential linear, homogeneous differential equations, which the alien derivatives are going to verify. And following this line of reasoning, we arrived very quickly at the bridge equation, which consists of three things, you see on both sides, the full solution with the maximum number of parameters, on the left-hand side, the invariant alien derivations, and on the right-hand side, the ordinary differential operators in the parameters precisely, in the parameters of the equation, and sometimes also in the variable itself. So, these operators carry the source constants that they ask coefficients, otherwise they are subject to no other constraints than making sense, that is to say they must bear off a similar exponential on both sides. So, you see this reduces the part of analysis to the minimum, it makes everything more or less formal, and we arrived at, so in this case, the nature of the active alien algebra is obvious, it is simply the native alien algebra generated by these sub-omegas, these ordinary differential operators. So, in this case, just two remarks, in this case the display, it looks like a magnified, actually, full solution, because the power series in it are going to be more or less the same, but they are two different. First, they carry in front of them Stokes constants, and then that indexation, see I recall the definition, instead of being by simple frequencies, by simple omegas, the indexation is by strings of omegas, so it is a much richer object, and then it has this property, which I mentioned a minute ago, of extending to all relations. So, this is, it is an object which has no classical equivalent, and which is extremely, I cannot overemphasize this enough, and this is extremely useful. And then, just a remark, a funny remark, I mean, resurgent functions, meaning in this case, in the case of, in all cases, in fact, they have a cohesion, which ordinary solutions of differential equations do not have, and cannot have, in the sense that knowing one part of the full solution can constructively lead to the reconstruction of the whole solution, even of the original equation itself. You can think as an analogon of an irreducible polynomial of a Q, if it is reducible, I mean, knowing one root will not tell you anything about the whole, the other roots, but if it is fully reducible, of course, you can, you know, the full picture, you can reconstitute the full polynomial from one root. So, they, they go here, in the, they have this property. Now, let us, to better understand the interplay between equational and co-equation resurgence, we are going to focus on a problem, a model problem, which manifests both types of resurgence. See, we start from the equation, the blue equation with a small t, time variable, system of new equations, non-linear, and with, in front of the system, and possibly in the other coefficients, perturbation parameter epsilon. Now, it is convenient to switch to the critical variable and to the critical parameter and to work at infinity instead of the origin. So, we move from t and epsilon to z and x, and the system becomes the red system down here. So, let us take along, we are going to work on that for the rest of the talk. So, let us take a long look at basically a system, it's, I reproduced it here in any case, and just one remark actually, we can assume without actually losing much that the perturbation parameter is absent from the coefficients b, it's present there would, wouldn't add anything of substance to the analysis, it would simply complicate notations. And then a second remark, there is a special case in which a very special case, a special, in the coefficients b that reduced to negative power, meaning to 1 over z, to a constant of a z. In that special case, the two, the variable and the parameter coalesce into a product z times x. So, in that case, obviously the two resurgences coincide. So, something of this sameness is going to survive in the general situations, but on the whole it is fair to say that the differences are going to dominate. So, instead of instead of working with a full solution, actually, we are going to work with an object which is information equivalent, but more flexible. It is a formal automorphism which the normalizer, which takes the normal form of the equation and it's a trivial normal solution to the equation, to the system itself and its non-trivial solution. So, this normalizes, direct and reverse, consists of two ingredients, ordinary differential operatives, d, that encode the Taylor coefficients of our system. And then the main object from the point of view of resurgent of analysis, they are bi-resurgent monomials. So, you see down here in blue they have a double indexation, a two-tire indexation, the things in upstairs mean their weights, complex numbers, and downstairs the v's are simply analytic terms at infinity in the, on the Riemann sphere, with analytic continuation to the whole Riemann sphere and possibly any pattern of singularities there. So, again, I reproduce, they are going to be our main object. And the, so just a shorter side, I mean, this is Yusuf's terminology, these normalizers, they are just said that they are automorphisms. And this is, this reflect there being the contraction of ordinary differential, ordinary derivations, the d's, and a mold, I mean, these bi-resurgent monomials which are symmetrical with respect to the indices. Symmetriums simply mean that they multiply according to the shuffled product.  Instead of multiplication, you get zero here. And this is contracting symmetrical with derivations, you get an automorphism, and contracting alter-node with ordinary derivations, you get, again, a formal derivation. So, this is all our indexed object are going to be, to fall into one of these two categories, and we are going, I mean, every time to contract them, so as to get either automorphisms or derivations. So, very quickly, these, as you can see, above the bi-resurgent monomials, which I should say, I mean, this has to be justified, but actually the fact is that they carry, they are simple objects, but they carry the whole diversions once, and the resurgents, once they have been understood, I mean, in a sense, everything has been understood. So, we are going to focus on them. They are defined by this equation two, and in this case, I mean, coefficient, in their case, in this instance, equation resurgent is simplicity itself. Borel takes you from z to zeta, the conjugated variable, and the recursion equation simply actually simplifies. You can see equation two. So, this equation three, I mean, immediately give you all the information about the the equation resurgents in this case. It tells you exactly which alien derivations are going to act on that, and how they are going to act. They are going to produce elementary, sorry. So, equation resurgents is a trifle in this case. Now, co-equation resurgents is quite, you see, in this case, the recursion equation instead of simplifying gets messier. We get equation eight and so on. I mean, when we perform Borel from the x to xi, the conjugated variable, it becomes a partial differential equation, which is suitable limit conditions. And it is in the case of a depth one, I mean, the solution is obvious, but for larger depth, there is no simple formula for solving this recursion solution. So, we need a new operation, which is precisely the weighted convolution. So, actually, again, for perspective, let us say what we are saying in advance, what we are going to do. We need four things. We need a weighted convolution to express the bioresurgent monomials with respect to x. Then, to express their own alien derivations, we are going to need a second type of weighted convolution. This time, it will be a symmetrical, an alternate with respect to the index. And then, we will need exact formulas for finding the alien derivations of these two types of weighted convolutions. And then, to express, actually, the alien derivations, the alien derivatives, we need a new object, which is one of the styles of this theory, the translation coefficients. So, first, the symmetrical convolution is given by a very complicated multiple integral with a complicated multipath. And it is very nasty, in a sense, very contorted. But the fact is that all the calculations for quick resurgence are going to be based on that. So, we have to live with it. But we should actually mark a pause and describe this integral. You see, upstairs, there are weights, and downstairs, there are germs in the Borrel plane at the origin, which have infinite continuation, but usually highly ramified. These are the inputs. The output, this is a statement, is exactly of the same type. In germ, the analytic germ, they're the origin, with and as continuation and unimidication. So, we cannot describe this integral in more detail, but we can give more telling, actually, characterization. Just like ordinary convolution is the Borrel image of ordinary multiplication. In the same way, weighted convolution is the Borrel image of, let us say, a weighted multiplication, which is a simple interval kernel, this one here. And on this formula, although it is of no practical use, actually, all the work has to be done in the convolutive plane, the Borrel plane. But formally, it's a nicer picture, and it has the advantage, the merit, at least, of making a symmetry obvious, because the kernel itself is quite obviously symmetrical. So, now, as I said, we need a second to get a closed system that expresses everything. We need a second type of convolution, this time, alternate with respect to the indices. It can be defined in any of three ways, either as a superposition, as a finite superposition of symmetrical convolutions, or by a direct integral formula, which is even more complex than the last one we've seen, or, again, in the multiplicative plane, by a simple kernel. And this kernel, as you can see, I mean, the first convolution is called, we call a second wheel. I'm sorry, but we have to introduce these objects. We cannot do without them. And going from one to the second, from the first to the second, actually doesn't involve significant complications. So, again, I have to be content with their somewhat schematic survey. But the aim is to actually get to show that there exists a machinery for dealing with all situations, not so that we're not condemned to deal with special case after special case after special case, which is not a very inspiring way of doing mathematics, but I think something that deals with co-equation resurgence once and for all. So, what is the relevance of these two convolutions? Well, the first one, the symmetrical one, it's quite simply that the body's urgent monobules with respect to x can be expressed in the Borel transform in the xi plane can be expressed as weighted convolutions of what? Well, of these germs. Now, this is rather strange. You see, these germs, Ti, xi is in the Borel plane, but it is built from data, which originate from the multiplicative z plane. So, we have this very unusual and rather unpleasant jumble of two structures, multiplicative and convolutive. This is of the essence, actually, of co-resurgence, co-equation resurgence. This is how it is, actually. You cannot help it. And the relevance of the second weighted convolution is simply that we'll need that to express the alien derivative of the first type of weighted convolution and also the second type. This time we don't need a third one. The buck stops there. We get a closed system. Now, all this is fine as far as it goes, but it leaves the main difficulty unresolved. The thing is, how do we calculate the alien derivatives of these weighted convolutions? Now, the first idea would be actually, well, we might look at the integral formula and then take the endpoint close to a singularity and then look, see what happens. But, actually, it would be the height of madness, actually, to proceed in this way. Because just look, even in the case of ordinary convolution, as soon as we move away from the origin, the integration path has a way of getting impossibly contorted and well, convoluted. And this is because we must not only dodge the singularity themselves, but also the mirror image, images of the singularity with respect to the midpoint. To the point, mean halfway between the origin and the endpoint. And this is for ordinary convolution. Just imagine what it can be for a weighted convolution. Because it is, again, it is a binary, the r-ity, r, the number of the depth, is irreducible. Meaning that a weighted convolution cannot be broken down into a chain of binary operations. It has to be taken directly in its full horror. So, we must come up with something else. And the only salvation, actually, is to find a set of test functions which meet three conditions. There must be numerous enough, actually, to model the general ramified functions. There must be stable enough to self-reproduce under all the operations, convolution and and weighted convolution. And then, they must be, again, simple enough to lend themselves to alien differentiation in terms of themselves, again, to get a closed system. Fortunately, there is such a system is at hand, they are the hyper-logarism. But, again, I mentioned this feature, this interference of the multiplicative and the convolutive structure in the equations. And in actual fact, the hyper-logarism was specially suited for that purpose. Because they are stable with respect to convolution and with respect also to ordinary point-wise multiplication. But there is a, there's a hitch here. We need to differentiate, we will have to juggle two types of indexation because convolutions mean adds singularities in projection. Whereas point-wise multiplication obviously keeps singularities in place. So we'll need to, I mean, to use both the so-called positional indexation, which reflects the position of the singularities themselves, and incremental indexation, which measures, indicates the gap between one singularity and the next when they are on the, okay. Now, unfortunately, when everyone is very familiar with hyper-logarism, but here it's a question of, I mean, they are capable of many indexations and many forms. I mean, here we need a very special two indexations, and we cannot spend too much time on that, but the formulas are there. And there's a whole set of formula which we'll, we'll be of constant use in the stake well. The formula is for finding the alien derivations when they are elementary. You see, when under alien differentiation, when the hyper-logarism when taken in this basis, behaving exactly the way they produce elementary stocks constant, the red objects with, and they are the logarithms themselves, the hyper-logarism or symmetrical with respect to their indexes, and the associated monics, the stokes constants, are all general with respect. So that we'll need all the time, and then we'll also need to know exactly how they behave under ordinary partial differentiation with respect to the indices, there are formulas for doing that. And then the jump rules, the way they have been defined, these monics or piecewise analytic functions defined on the finite number of C to the R. And we know the hyper-surfaces which limit, which limit these various domains of analyticity, and we need jump rules to describe the passage from one domain to the next. So these are, these are the tools. Now, the first main set of formula, when we, when we consider a weighted convolution with the simplest possible inputs, ordinary simple poles, what we get is far from simple. You see, depending how I wrote here the first for the depths one, two and three, we get a number of terms, we can express everything in terms of a superposition of hyper-logarisms, I mean in total there are quite a lot of them. The so-called odd factorial one times three times five times, et cetera, two R minus one, and you see that the, the U's and the V's, the U's in blue, the V's in red, behave in a very specific way. There is of course an induction behind all this, there are actually two inductions, one which adds indices and one at the end and another which are forward going, which I think this is at the beginning, et cetera, what will be so, but this is not enough, I mean our inputs are not simple poles, I mean of course this would be enough to deal with the case of metamorphic inputs, but we want to deal with all cases, so we want to have a general hyper-logarithmic input. Now, there is again a formula for that, I didn't write it here, but it's in the notes which I posted on my homepage and in various papers, but there is an important remark here, the inputs themselves mean they are hyper-logarism and the output is also a superposition of hyper-logarisms, but the inputs have to be inserted in a positional notation, in positional indexation, whereas the outputs have to be noted in incremental indexation, whether there are tables in my paper, I mean the number of terms which you get is even larger, the formula in blue up there tells you how many, if each of the inputs has depth di, this tells you the number of terms, you see, just to understand how complex the whole thing is, how devilishly complex it is, just take a convolution, a weighted convolution of length four with inputs which are themselves hyper-logarism, each of them again of length four, what you get is close to 10 billion terms, of course there is a combinatorics behind it and the symmetry, the symmetry of all makes everything rather manageable, but this is just to say that I mean following the integration path, the multi-path wouldn't have got us anywhere, we have to develop singularity combinatorics, so there is a formula for calculating the weighted convolution of hyper-logarism and since they can approximate anything, we can take the weighted convolution of anything, so now here comes the main surprise, I want at least to be able to describe these very strange objects, I mean the source coefficient, the water places, the source coefficient, the tessellation coefficient and their essential discreteness, so you see in a sense we have everything, we have expressed the convolutional products in terms of hyper-logarism and we know how to alien-differentiate them, but here comes the surprise when we take the sum, the sum, huge sums and there's a gap in complexity and usually such gaps are attended by emergent properties and here the emergent properties is the emergence of discreteness, so let's say we have no time, let's take an example, perhaps at length 3, we get exactly 15 terms and they are all, they are hyper-logaring and all the indices on top of them have the same length, so if we apply an alien derivation of that, I mean u1 times v1 plus etc, u3 times v3, each of the terms is going to contribute something and we have to get the result, we have to replace each of these 15 hyper-logarism by the corresponding monic, so the x disappears and we have this sum, now and the surprise is we know how to partial differentiate these monics with respect to the indices and now take any u or any v and apply the rules for partial differentiation and you find zero, but this is not obvious on this formula, but this is what you get and all the way to infinity, but they are not constant, they are not zero, if we apply the jump rules we find this recursion equation in red, which I have to explain the notation, but I can take my word for it, they are a fine number of domains on which the function is constant and they are jump rules, which amount to explicit recursion, which can describe the whole thing and this leads to, again I cannot explain in due detail the formula, but these recursion rules leads to an explicit and simpler expression for the desolation coefficients, but they have one effect actually, they are highly polarized, they are simple, they are elementary in the sense that they involve only sine functions of elementary functions which are homographic in each of the u's and each of the v's, but you see this is, we have the choice here between their locally constant and discrete functions, these desolation coefficients, but we have the choice between expressing them as sums of hyper logarithm, which is slightly incongruous obviously, but in principle and an expression which is much simpler and more appealing, and also from the practical point of view, infinitely preferable, but highly polarized, this is a situation which is not unusual in mathematics, but it is a rather extreme instance of such a situation, and in fact the simplicity of these desolation coefficients is deceptive, actually they are rather mysterious and highly interesting objects, which are lots and lots of properties, just mentioned three, they are invariant on their their symmetry with respect to their indices, they are double indices, they are excuse me, they are alternal, and then they are invariant under a very important involution, this is called swap, which exchanges upper and lower indices, and that makes them be alternal, mean twice alternal, this is a very important property in arithmetic, and the study of multisitters and all that, and then again they are discrete, and for a depth one they are trivial, they are always equal to one, but at a higher depth, surprisingly they are not constant, but they are almost always zero, if you mean by any measure, and what else, well many other properties, so they are quite highly interesting objects, now we are in a position with the help of the these two convoluted convolutions, and with the help of these desolation coefficients, to express, to do what we set out to do at the at the outset, mean to express the alien derivations of any convolution product, there are formulas for this, they involve three things, the express, I cannot describe them in detail, but just I'll say it in words, we can express the any alien derivation, alien derivative of a witted product in terms of three things, a new convoluted, a new witted product with new inputs, which are either the translates of the old inputs, or alien derivative of the old inputs, and new weights, so this formula exists, I'll have to skip them whenever we should, you know anyway if you care for that, we deal in the in the slides, which I posted on my homepage, and now at last we can describe the, we can give a complete description of the two types of resurgence, the first, in the first, I mean in terms of not of the complete solution, but as I said of the normalizers, which are more flexible, the first bridge equation is quite simple, what is one of the standard forms upstairs, I mean up there, and it involves as usual ordinary differential approaches, which in this case depend on all parameters, including this parameter x, and it is a constant in z, but it is an entire function of x, so it describes everything because it can be iterated in terms of itself, so it gives all the information, not so with quick equation resurgence, because the first bridge equation, which you find the second one, looks formally the same, but actually the q's, which on the right hand side do depend on x, but not as an entire function, because here x is the resurgence variable, the resurgence variable, so to describe the resurgence in x of this new object, it takes the third bridge equation, which thankfully is closed, it expresses the alien derivation of q in terms of q itself, now this is in the case of holomorphic, for the first equation it is absolutely general, no assumption at all, for the second equation, for the equation two and three, we must assume that the data, the p's, are holomorphic, if they are not, then there is an added complication, there is a new level of complexity, instead of only q's, you have two series of new objects, mean new disurgent objects, q's and p's, and they are related by the tessellation coefficients, so again we would have to mean describe, to look at this calmly, and we cannot do this here, but the object again, it was to give a survey, to show that there exists a machinery for dealing with the general situation, so you see I'll have to, to skip the the end, we'll just say it very quickly in words, but let us suppose a little and take stock of the, what we've seen or achieved so far, you see, contrary to equation resurgence, which is simple enough, although it covers a huge, huge ground, I mean, but it is simple, I mean conceptually in terms of calculations, a coefficient resurgence is, there is a stratification of four level stratification, you see, the inputs themselves, they are, let us say they are hyper logarithms, then we have the weighted convolutions of these inputs, they are huge combinations, I mean huge clusters of hyper logarithm, again with emerging properties, quite unexpected, and then we have the Qs, which are again, I mean, large sums of the such clusters, and then in the general case, in the, with ramified inputs, Bs, we have a fourth layer, which again, I mean, the P's and the Q's and the P's up top, in the last layer, and the passage from the Q's to the P's is again mediated by the tessellation coefficients. So, then again some differences, I mean, what equation resurgence, we'd only to assume that the inputs B had to be jerks at infinity, I mean, no, in the case of coefficient resurgence, we had to assume that they were in the multiplicative plane, they admitted the endless continuation with, again, uniformity conditions. And then in the, for the first bridge equation, the index reservoir is simple enough, it's just, it is generated by the multipliers by the lambdas here in this equation. In, not so with coefficient resurgence, it is much more complex, it is the linear expressions of the weights and the singularities of the inputs. So, you see, but to make up for that, the source constants simplify, they become, I mean, the tessellation coefficients, which are, so there is a trade-off between the complexity of the set of omegas of active alien derivation and the complexity of these source constants. And then, well, many other properties, but I want just to say in a few words, there are only five minutes left, the two, what is the matter, actually, with autarchy and with isography and autarchy. You see, in the case of coefficient resurgence, we have, the q's are, the q's and the p's are resurgent functions. But you can imagine that they are, they stand in close relations, with the a's, the a's of omegas of the first bridge equation, because remember, there is a case when both coincide. And so, in the first case, they are entire functions of x. In the second case, they are resurgent functions of x. And they are not exactly the same, but they, there is a close relation. We go from one to the other, one system to the other. So, they have this double property of being entire and resurgent in sectors. So, obviously, this imposes on the active alien algebra certain constraints, because otherwise, there would be an effective ramification at infinity. If there is to be no ramification, or only a finite ramification, there has to be some constraint. But the, the interesting thing is that these constraints assume the form of this form in the each operator in the active alien algebra, each ordinary differential operator kills a certain differential two form, which I called the isographic form. Why? Because it had to be given a name. And so, I gave example, I gave three examples and I'll produce a paper, hopefully, with many more, but of a so-called, such isographic forms. And then autarchy. Well, autarchy is precisely this, this property of, well, I'll finish on that. Autarchy. Autarchy is the opposite of anarchy. Autarchy is usually spelled with a key, but I wanted it to rhyme with anarchy. The, you see, it is, you see, roughly the, the autarch functions or entire functions, who the syntotic behavior in the various sectors is fully described by resurgent syntotic expansions, which in turn generate on the alien differentiation a closed finite system, their autarchy relations. And so you see, despite being transcendental, the autarch function has a strong algebraic, I mean finite and algebraic flavor about them. And moreover, they are not freaks of nature. They are quite common, actually. If you take something at random, of course, it will be anarchy. But in practice, it will be, I mean, if it is something of any use, it will turn out to be autarch. And the showcase example of autarchy is, of course, the inverse comma function, you see, it's on its own, it's an entire function. But there is, on the right side, there's a syntotic expansion, which is well known, and which, I mean, combines with the first ramified factor, actually, to destroy the ramification and to produce something which, despite resurgence, turns out to be entire. And then the showcase, the instance of anarchy is, of course, the xi function, which is associated with the zeta function, the Riemann zeta function, because, alas, there is this strip, which defies accurate description. So, and the two things mean isography, isography and autarchy, they are closely connected. And as you mean, I gave three examples. But the first one, in keeping with our philosophy, we deal with the bioresurgent monomials. We want, I mean, systematically, as a matter of principle, we want to study the end to solve the difficulties at the most basic level. And so the first example is devoted precisely to the bioresurgent monomials and to this double genus-faced nature, being entire and being resurgent. So, one more minute, if I may. So, I wanted to say something about the other types of resurgence, but we have no time for that. I just want to mention, in 30 seconds, a spin-off, I mean, a fallout of this theory. When we describe the weighted convolutions of hyperlogarism or the tessellation coefficients, you observed, certainly, that the U's, the weights, and the V's, the singularities in positional notation, interacted in a very specific way. I mean, the U's got added cluster-wise, the V's got subtracted pair-wise, with additional constraints. And this gives rise, actually, to an interesting theory. This gives rise to the so-called flexion structure, which is actually made very informal. This is the sum total for all interesting operations, which you can obtain by using four basic flexions operations, which are four flexions, which combine the U's and the V's. The W's are two-tire indices, meaning V's and U's, and the flexions can combine them, transform them in precisely this way, adding the U's. And this flexion structure contains, I mean, the joule inside the flexion structure, is a set of a certain algebra and a certain group, which are Adi and Gadi, which have the properties of preserving double symmetries, which is extremely useful for in arithmetic for studying what I call dimorphi. Dimorphi, you can think of it as the property for a set of transcendental numbers of a Q to be stable under two different multiplication tables, which are difficult to combine, actually. So the multisiters and the hyperlogarithms fall precisely. They are highly interesting and highly useful, fundamental transcendental numbers, I mean, and they are dimorphic. And this structure, the flexion structure, is extremely useful, actually, to study that. And they mostly over the last 15 years or so have been basically into this dimorphic business. And so I wanted to mention this spin-off. But actually, these transcendental numbers are precisely the typical ingredients, the building bricks of the Stokes constant for equational resurgence. So in a sense, we have come full circle. We have here a nexus of objects, which is very closely knit, and in my view, rather harmonious. So time to stop. Thank you. Do you have any questions? I have a couple of questions here. This is a photographic form, which you mentioned. Is it a non-degenerate balliniform? Yeah, it is actually, even in the case when the number of variables is odd, even in that case it turns out to be a symplectic form. But it is not given naturally in that way. It is not. This is interesting because there are quite different. I mean, there are also resurgence when you consider symplectic systems. In certain cases, we're on top of the resonances or the standard resonances implied by symplecticity. You have other resonances. Then resurgence gets grafted into this. But the underlying symplectic structures get grafted onto that. And to that, the ease, you see, of the bridge equation, they derive from a potential. But they are real, they are continuous. So in that case also, we have the similarity superficial because in that case also you have resurgence constants which derive from a potential. But they are continuous. They are indexed. There is no discreteness about them. But there is an interplay. But yes, there is a symplectic structure behind it. But it presents itself naturally in an unusual form. I gave three examples in the notes. There is also a short question. There is also desolation coefficients which are zero plus minus one plus minus two, yeah? Yeah, after a lot. Yeah. After a realization, you see that very often zero can be back measured as a function of some complex parameters. Let us say, well, in every sense, you can think of, actually, if you take the coefficients at random, it would be zero most of the time. Or if you consider them to be a function on the Riemann sphere to time in, and you take the Borel measure, it would be, although I did not actually compute the exact Borel, but this is at least spectacular actually. I mentioned the values for the first depth four, actually. They are almost always zero. Again, the simplicity of these creatures is highly deceptive. I have to say, well, at least I do not understand them fully, although they are there. I mean, they are described. But we would like actually to get other formulas for them and to know more about them. So there is a lot of work to do in this line. One more question. Thank you.


All right, I'm getting thumbs up. OK, so technical debt trap. This is going to be a little bit interactive, not a lot. I'm not going to ask you to do any kind of exercises or anything along those lines. But as we go through this, I'm going to ask questions of the audience and just feel free to raise your hand or shout something out when those opportunities present themselves. I am, and we'll do this pretty quick, I'm Doc Norton. I am co-founder and CEO of a consultant called CTO2 out of Chicago in the States. We operate worldwide, and we do a lot of process and engineering coaching for organizations. A lot of our clients are kind of post-agile. They've gone through some kind of an agile implementation. It's not quite working the way they wanted it to. We help them figure out what went wrong or what else they could do differently. And our focus, a lot of times, is not just on the tech side, but also on the people side. Because those two things go very strongly together. And that's just me with a lot more hair everywhere. So first question for everyone here. What is technical debt? We're going to talk about technical debt today. When you came in today, what does that mean to you? When you think of technical debt, what comes to mind? Legacy system? Refactoring? Code quality? Defects. Defects? Wrong investments. Wrong investments. Rework? All right, cool. So yeah, I think these are all kind of elements of it. Especially as we, today's definition of technical debt certainly encompasses all of those things. Does anybody know where technical debt, where the actual phrase came from? Kind of a history of it, right? Anybody know who originated this metaphor? Ward Cunningham, that is correct. So it's actually fairly old. In 1992, in an OOPSLA paper, Ward started to talk about technical debt. And he told us, look, shipping first time code is like going into debt, right? And a little bit of debt actually speeds development. And that's fine, right? As long as you pay it back fairly quickly with a rewrite. Now the danger actually occurs when that debt isn't repaid. So every minute on not quite right code counts as interest on that debt. And in this, the OOPSLA paper was much longer, but this was one of the things that he talked about in this paper. And this is where the actual metaphor came from. Now, a couple of things. One, the reason that it is technical debt other than any other kind of phrase is this OOPSLA paper was actually about a project that Ward was working on for a client of his. And he was working on the YCASH portfolio management system, which is a financial system. So his customer was in the financial space in the late 80s, early 90s, right? At that time, this was before the time where we decided that shareholder value is more important than actual value. And it was a time before venture capitalists convinced us that we should launch things on massive leverage, right? So back then, what we knew about debt was that it was a very risky venture. It was not something that was to be taken lightly, right? Today, our view of debt has changed. So that doesn't help the metaphor very much, right? But I wonder often if Ward had been working for a hospital, or if he had been working for a company that took care of trees, right? Arboretum, something along those lines. What metaphor would he have used? And would we be talking today about code in terms of not debt, but long-term and short-term care, pruning back things that hinder growth, health, management, right? But because his client was in the financial space, he went with a metaphor that they would understand and that was debt, right? Now, I wanna actually dive into this last sentence here in Ward's description of technical debt, because I think it's really important. Ward is actually quite deliberate about the things that he says and the way that he says them, but there's subtlety in all of it. And this sentence, I think, more than anything else, actually clarifies his perspective on technical debt. He says, the danger occurs when the debt is not repaid, and every minute spent on not quite right code counts as interest on that debt. So let's decompose this a little bit. What words does he choose? What does he use in this definition? He says, danger, right? He doesn't say challenge or hurdle. He doesn't say concern. He says, danger. Danger is fight or flight type of stuff, right? This is high risk. That's danger. He also says, every minute, every minute that we have technical debt is dangerous, right? Not every year, every quarter, every release, every day. Every single minute that you have technical debt is dangerous, and what is technical debt? Not quite right code. That's significantly different than sloppy, shoddy, dashed together, right? Code that's just not quite right. Now I'm here to tell you that technical debt is in fact good. It is good because by Ward's definition, it is a strategic decision. What it allows for is rapid delivery, right? We can get something done fairly quickly, right? We can get some feedback based on that, and then we can correct our design, right? Now sometimes, rather than a strategic decision, technical debt can be an indication of learning. So in this case, what happens is we put something out into production. Of course, it's good quality, right? As best as we can do at the time with what we know, but we put it out there and what we discovered was that it didn't quite meet the market need. It wasn't really what we wanted or what we needed. So now that we know what we need, we have the opportunity, our implementation doesn't match, we have the opportunity to actually make that change. So we could do something deliberately or it could be that we discovered it later, right? Now technical debt fundamentally, we kind of talked about this, it's a metaphor, right? And in this case, it is a metaphor for here be danger. And I honestly believe that metaphor is rock, which by the way is a metaphor. But they are a way for us to talk about complicated things that we may not have a shared understanding around, right? So I've got some topic. Let's say that topic is refactoring code that I'm going to take something that was done and I'm gonna go back in and work on it again. And the person that's paying me to write this system wants to know why do you keep touching stuff that's done? So I might in an effort to explain this to them, take something they understand, debt, and equate it to this thing that I'm trying to do because they wouldn't understand refactoring necessarily, right? And that's what metaphors are for. And they're very helpful in that instance. We can use common language and achieve an understanding but there's a problem with similes and metaphors. That problem I call metaphorses and this is when metaphors go wrong. What happens is we have the actual topic which some of us understand and some of us don't. We have the replacement topic which theoretically we all understand. So we begin this conversation about debt when we're really talking about refactoring, right? And I get what debt is. Oh, I know what that is, yeah. So I start talking about reckless debt. I start talking about high interest debt and loan sharks and student loans and blah, blah, blah, blah, blah, right? And the next thing you know, we're not having a discussion about refactoring at all. We are acting as if debt is the thing and yet still sort of equating it back, right? I've had these instances where a guy that I worked with once was complaining. He said to his boss, you keep asking us to fix the code while delivering new features. It's like you want us to refuel the car while we're still driving it. Five minutes later they're having an argument about the logistical possibility of a tanker pulling up beside the car and refueling while you're going down the road just like jets do in the air. We're not talking about the thing we're supposed to be talking about, right? This is what happens when metaphors go wrong. And in our industry, this is exactly what happened with technical debt. People heard this phrase. They knew what debt meant and they went with it, right? And the next thing you know, we are talking about short-term intentional high-interest loan sharks, right? We're talking about inadvertent reckless debt in the third quadrant, which we will look at in a minute here. And this became so pervasive in the industry, so commonly accepted that it started actually making its way into literature that our leaders were delivering. Now I know most of the folks on this list, if I can know all the folks on this list, I respect all of them, right? At some time in the past, these are words these folks used to define technical debt, right? Cut a lot of corners, quick and dirty, hack it in, sloppy. But that's the way that the industry began to look at it, right? And eventually this led to these detailed arguments about what is or is not technical debt, right? And Martin Fowler said, okay, look folks, we're basically at this point where we're having this weird argument about is it debt, is it not debt? This isn't healthy for us. It's not helping us at all. So maybe we should look at this from a different perspective. And he proposed the technical debt quadrant. How many of you are familiar with this thing? Handful, okay. All right, so technical debt quadrant. Basically what Martin told us was he said, look, if we look at debt from a couple different perspectives, first of all, debt is either prudent or reckless. It is the result of prudent or reckless behavior, right? So I am behaving well. I'm doing all of the things that I believe to be the right things. That's prudent behavior. Or I'm cutting corners intentionally. That's reckless behavior, right? It can also be deliberate or inadvertent. I am doing this thing with intent or I don't realize that I'm actually doing this thing, right? And so we look at this quadrant and it helps us to understand the different types of debt, technical debt, and helps us to maybe think about where they come from and how we might resolve them. He goes on to say that, okay, so reckless and inadvertent, what might that be? So reckless and inadvertent might be that you don't know about good architecture. So what you're doing is not good behavior, right? It's reckless behavior. But you don't actually know that you don't know, right? Reckless and deliberate now, this is where we actually make a conscious decision to cut some kind of a corner because, well, we just got to get it done faster, right? So we're still acting recklessly, but we know that we're doing it, right? Prudent and inadvertent. And this one, I had a hard time with in the beginning because it seems strange to me that you could accidentally behave well, right? But that's not actually what he means. You are not inadvertently acting prudent. You are prudently acting and you learn something as a result that you didn't expect, right? So now we know how we should have done it. We built it well from a technical perspective. We put it out there. The market didn't respond to it the way that we had hoped. We learned something from that. Now we can make the change, right? And the last one, prudent and deliberate by Martin's articulation is we must ship now and deal with consequences. Now, this whole thing came out in about 2009. I had the good fortune of being at ThoughtWorks at the time. I had, at the beginning of 2009, had written an article about messy code not being technical debt. Shortly thereafter, Robert Martin wrote a very similar article and then I was sitting next to Fowler when he was actually creating this thing. And he and I got into a bit of an argument about the whole thing. But eventually I couldn't, I couldn't, there were things about it that bothered me and I couldn't necessarily articulate what they were, right? But this persisted for a while. After this came out, actually, Ward kind of popped his head back up. So remember, 1992 was when Ward said, this is what technical debt is, right? 2009, Ward pops his head back up and he says, we got a problem, guys. Many have explained the debt metaphor, confused it with this idea that you could write code poorly with the intention of doing a good job later, right? You have confused the debt metaphor with the idea that you can write code poorly. That is not at all what it is.  What is refactoring? Say that again? The debt itself is refactoring? Okay, more technical definition of refactoring. What is it? Okay, not changing the behavior, but rewriting, right? So refactoring is changing the implementation without changing the behavior, right? That's what refactoring is. Now a lot of us use it to mean like I ripped it a new one but that's not what it's supposed to be or I changed it, right? Refactoring technically is I changed the implementation but didn't change the behavior. How would I change an implementation and know for certain that I didn't change the behavior? Say it again? If the code's not clean enough I would have a hard time doing this, right? How would I know that the behavior is still the same? Tests. So in order to have technical debt you have to have a system that is cleanly written is refactorable and by inference has tests around it, right? This means that clean code is a prerequisite for technical debt. You can't have it without clean code, right? Ward came back out a little bit later in 09 on Twitter and he said, okay, folks, if we really want to run with this thing, let's run with it. Dirty code is the technical debt as a pawnbroker is to financial debt. Don't think you are ever going to get your code back, right? If you are writing messy code, it's, you want to go with the metaphor? It's just like getting a loan from a pawnbroker. You're never gonna see the thing back again, right? This is not a winning strategy. So question becomes, all right, so we got all these different ways of looking at technical debt, right? A little bit of a check. Do I have technical debt? Is the code clean? Is it tested, right? Is there a learning objective or event? So we are pushing this thing out into production. Maybe what we're doing is we know that eventually we need to be able to purchase multiple items in a shopping cart, but the first thing we're gonna do is just put a standard purchase flow out there and let's see if people actually make it through the purchase flow well, right? If they don't, we're gonna go back and change that until we get that right, then we'll introduce a cart. So we know that we're gonna need something later, but we wanna get something out there soon so that we can learn, right? So that would be an objective or an event. We push something out there and discover that the market actually wanted something different, right? Is there a plan for payback? Do we know when we're gonna actually remediate this thing? When are we going to bring our implementation in alignment with what we now know the design needs to be? And is the business truly informed? Not, well, I told them, but are they actually informed? Do they know what's going on? If you say no to any of these, even one of them, then you actually don't have technical debt, right? You've got something else. So the question, of course, is what do you have? If it's not technical debt, what is it? It's a mess. It is a mess, right? Now, actually, and I like this, mess is a good description, but I found an even better word for this. Cruft, it is cruft, right? Why is that a better word? It's a better word because in several dictionaries, a formal definition of cruft is redundant, old, or improperly written code. That is the word that we're looking for to describe these types of things, right? It's cruft, it's not technical debt. Now, I've given this talk many, many times in various forms, and I've been in this discussion many times with people over the years, and one of the things that I started hearing was, all right, dude, that's really cool. You've got an opinion on technical debt, but it's just semantics, right? Like you're just making the meaning of words be important or something, just semantics. Well, I say that it's not just semantics, and the reason is if we agree that technical debt is good and we also agree that quick and dirty is technical debt, then we agree that quick and dirty is good, and I cannot abide by that. I have not seen one project that has been written in a quick and dirty fashion and actually sustained and succeeded. There are strategies for slap it together and figure some stuff out, but most organizations want you to slap it together to fix some stuff out and then build on top of that, right? And that doesn't work. So I talked about the technical debt quadrant before and kind of my concerns with it, right? The first thing that I noticed was this right here. Deliberate, prudent, but the wording is we must ship now and deal with consequences. It sounds deliberate, but it doesn't sound prudent. Dealing with consequences doesn't sound right to me. So I thought, you know, I would have preferred that this actually said, let's deploy and gather more information, right? We have a learning objective. We're going to deploy our well-written good code and we're going to see what we learn from it. But that wasn't enough for me. There was still something about this that just kind of irked me, and I was having a hard time articulating what it was, and I finally decided, you know what? What if I looked at this outside of our profession? What if we looked at this idea of technical debt in some other, you know, in some other realms, in other fields, if you will. So technical debt in some other fields, right? Construction. Can you see what's wrong with this building? Yeah, right? So, and if you look at this, like I've had people say, oh, no, no, no, no, the building settled. It wasn't their fault. No, no, no, the brickwork is actually level. The windows are crooked, right? Now, if you paid, you know, a good amount of money to have this thing built, and then the general contractor comes back to you and says, yeah, see, we incurred some structural debt because we had to meet your deadline. So, you know, we should probably discuss a payback plan for that, right? That's unacceptable behavior in that field, right? Automechanics. Same thing, right? Oh yeah, we just incurred some mechanical debt. Doesn't make a whole lot of sense. What about medical? Right? Yeah, see, we incurred some health debt during the surgery. It's kind of like you paid for it, you know, with a credit card instead of with a home loan. This doesn't make sense in any other field. Does it actually make sense in ours? If we actually look at these, right? The two on your right, I would say, those fall into the reckless and deliberate area of the quadrant, right? And benefit of the doubt, the one on the left, is reckless and inadvertent. I'm going to assume that the surgeon didn't decide, let's leave that there for the next surgery, right? That was an accident. So let's bring those back to the quadrant. So, there's our reckless and deliberate, there's our reckless and inadvertent. If we look at these things, what are they actually, right? What are they actually? When you look at them in another field, you wouldn't accept the idea that they're debt, right? What you would say is, you know, that mechanic was irresponsible and that surgeon was incompetent, right? That's what these are, is irresponsibility and incompetence. And if that's true, the only thing that is actually technical debt is prudent behavior. Right? So this has gotten a little heavy and I apologize for that, but it's a tough topic, right? So let's lighten it up a little bit. Does anybody want to play a game? Let's play a game for a little bit. So the game is cruft or debt. All right, cruft or debt. So what I'm going to do, there's going to be three rounds. They're going to get progressively harder, but trust me, the first one would be a good warm up, right? I'm going to show you some code. Within a very short period of time, I want to hear your opinion. Is that cruft or is that debt? Okay, we ready for round one? All right, I got pretty much got cruft, right? That's kind of universal, right? This is cruft. How do you know that? I mean, you can look at this and see that it's cruft, right?  So let's figure this out a little bit. The first thing I'm going to do is I'm going to collapse these curlies down so that I can increase the font size. So all right, that helps a little bit, right? If we actually look through this, I don't expect you to read all of this, but for whatever reason, we're connecting to a database and then we're pulling data back but we're iterating through every table in the data set. We're iterating through every single row, but we know specifically what we're looking for. So this is written by someone who doesn't understand their own tools, right?  So that helps quite a bit, right? And now actually we can introduce some abstractions. So we can create classes that receive data sets and then return collections of objects, right? And I'm not going to show you that code because your ORM should do that for you, right? It's nothing that you need to write. There's a proven set of systems that handle this for you, but it'll help us to remove some more of this crap, right? So now we're down to a fairly readable set of code, okay? And every time I look at this, I'm like, do I really understand it? I think I do, I'm not sure. But basically we're iterating through skills for an agent, we're comparing them against a list of skills that are in a queue, and then we're calling set agent queue skill for all matches and then I believe that set agent queue skill as a collection is then being used someplace else, right? The results of that. So ultimately all of this should be a view in the database based on a very simple query. None of this should exist, right? All of that code shouldn't exist. And before we move on to the next one, just kind of an aside, but it's interesting. I got that code off of a site called the Daily WTF. Is anybody familiar with this? So Daily WTF is Daily Worse Than Failure. I don't know what you were thinking. It is a site managed by Alex Papadimalus. And what Alex did was many, many years ago he got fed up with the type of just ridiculous code that he was finding in the source where he worked. And so he would pull out these ridiculous examples, he would anonymize them, and then he would publish them on the web as like, ha ha ha, look at this, right?  Alex reported to me at a bank when he started the site and the code examples were taken directly from the code base that we were responsible for. And I remember reading it and being like, you didn't anonymize that one enough, dude. But eventually he moved on and he started getting submissions from other folks. But yeah, we had inherited a very large and nasty code base and Alex did not like it. Okay, so let's look at this one. Is this crufter debt? A little bit harder to discern. Debt, okay, and why is that? It could be refactored, right? So would it then be cruft? It doesn't look messy. Okay, so I would, and this, these are judgment calls, right? I would call this cruft, right? And a couple of reasons for it. One, when I look at this, I can read all of the things, but I don't know what it does, right? I can see that, I mean, I can see that it's seeing if the state is Alabama. I can see if it's looking for a general agent customer type. I can see, blah, blah, blah. I can read through all that so can you, right? But you don't know what it's actually doing, right? What does that mean? What is the intent of this? So, luckily for us, there's a universal fix for code where you can't understand what the intent is, right? Done, now it's clean code. No, if you can do this, you can probably do better. The next thing that I notice about this, I don't know, it's a snippet of code, right? So I don't know what object this is in. I don't know what method this is, but there's a couple things I can figure out, right away. It sure as hell ain't the customer, and it's probably not customer type, right? Because I'm explicitly referencing those things. But I'm interrogating the snot out of my customer, asking a bunch of questions in order to make a decision. And the decision I'm trying to make is, is this customer federally regulated, right? Feature envy, right? This is a little inappropriate touching, right? This should be moved into the customer, where it would actually present much cleaner, and then we can just simply ask the customer, hey man, you federally regulated, right? So I would call that cruft, because it's an impediment in the actual design, right? And that's going to catch up to us later. That is, maybe it was inadvertent and reckless, and it's not as bad as some things that we've seen, but still falls into that category. All right, last round, hardest round to be fair, there's also bonus points in this round, if you can identify the joke that is hidden in here. The last line has never reached? Well, it should be unreachable, yes. What else, is there anything in here? All right, so first of all, is this cruft or debt? It's hard to say, right? Okay, does anybody get the joke in here? There's a Monty Python reference in here, no? Yeah, wrong audience. Yeah, so in Monty Python, there's actually in Holy Grail. There is a whole series where a guy gets asked the average speed of a, what, is it a swallow carrying a coconut? And the response is African or European swallow, right? So anyway, cruft or debt, so a lot of resistance in the, like a lot of hesitation, right? It's understandable, my opinion, this one totally depends. It depends, what does it depend on? How can it either be cruft or debt? It depends, it depends on your team's agreements, is what it depends on, right? It depends on how you look at this type of thing. If you are a very strict clean coder, I've read Uncle Bob and I know exactly what I'm supposed to do under all circumstances, then this is cruft, right? But for some of us, that may not be the case, this is actually fairly easy to read and it makes sense, right? It's got high psychomatic complexity, I've got a lot of conditions in here, but it's nice and clean, it's in a switch or a case statement, that's fairly easy to consume, right? And the challenge is, if I wanna clean this up, what do I need to do? Well, I need some kind of a polymorphic implementation, right? And when I do that, I'm gonna have a bunch of pseudocode here, I'm not gonna do the whole thing, but when I do that, I've busted this out into actually a lot more code. Now, it is more extensible, it is more maintainable, right? But that might not be a concern. Maybe there are only three options ever, there will never be a fourth or fifth or 27th option, and having that case statement is actually a better implementation for us in this domain, in other cases, no, right? So this one definitely depends. All right, so cruft itself is a bad decision, it's always a bad decision, right? You're a professional developer, this is what we get paid to do, this is our profession, right? You're going to create unintentional cruft, you can't help it, it's unintentional, right?  And it was you, right? We learn, we adapt, we change. So you're going to write it unintentionally, right? You're gonna have to clean up the existing cruft, right? So it's not a good idea, it's just a bad idea to intentionally generate it, it's going to be there anyway and we've gotta deal with it anyway. And it's the trap that we have, and it is called technical debt traps, we should talk about what the trap is, right? What happens is if we intentionally are writing cruft to get something done faster, which I still argue is not necessarily true in many, many cases, but if you are, what you've done is you've set a precedent for speed over quality, right? And the odds are, if you're having discussions about things like technical debt and perhaps velocity and blah, blah, blah, blah, that means that someone decided that we needed to install the agile, it probably means that someone read the book that says, you know, the team is going to come together, they're going to figure out what their velocity is, and within a few iterations, the velocity is going to begin to increase, right? There's nothing in the book that says how or why it's going to increase, but this magic thing happens and you start delivering faster because that's the promise of installing the agile, right? So there's an expectation of increased velocity and you've already set a precedent for speed over quality.  And eventually what happens is we actually have to ask permission to do our jobs correctly. Now, in our profession, we have become very good at this last piece, very good at it. So the way we do it is we declare the necessity of a massive rewrite. Java 8, blah, blah, blah, blah, blah, blah, blah, blah, right? Node, Elm, blah, blah, blah, blah, blah, blah. But the reality of it is I've seen code bases that were written in freaking RPG that are still being managed and maintained today, but they were well written and they do what they're supposed to do. The grand rewrite is very often not necessary. It is a way for us to escape from the thing that we did. The challenge is in that escape, we hope that this time we're gonna do it right, but the pressure is always to get that rewrite done as quickly as possible because we gotta get back to new features. So we just basically created another pile of cruft, but this time in a language we don't know nearly as well. All right? So how do we manage cruft? There's a few different ways of doing this. I mean, there's several, but fundamentally there's a couple of strategies that I see. The failing strategy is this idea of a cleaning sprint. How many of you have this kind of a thing? Right, you're going along, you're going along, going along, and then at some point someone, maybe it's because it takes six weeks to get anything into production and so during those six weeks you can clean code or whatever you wanna do, right? Maybe you actually schedule it, right? But you schedule iterations for cleaning the code. And you basically defer quality at any other time, right? You defer quality to cleaning sprint. And so you're focused on speed and velocity at all other times. What happens with that? So there's an extensive study that was done several years ago. I'll show you kind of the results of this. What we have here is the green line. So this is the cost of change which fundamentally equates to how long does it take to make a change in a code base, right? Over a period of time and actually years, right? So this is from the beginning all the way out to nine years. This green line is the cost of change on a code base that is being refactored continually, you know, well-written, clean, et cetera, right? And of course the cost of change is increasing because the overall complexity of the application or the volume of code is increasing, right? We're adding new features, we're adding new functions, we're, right? So the ability to keep it all in your head is getting lower. So the amount of time we have to take to kind of look at it and go, what was this again? Oh yeah, okay, right? This, not what I wanted to do. The top line, this top line is no refactoring. We just thunder along, right? Now you notice what's happening here is look at the curve of this line. We have on this scale another couple of years and this is pointed straight up, right? It is impossible to make changes to the code at that point, right? The cost is so high you can't get anything done. What's interesting here is the purple line is the cleaning sprint strategy. What happens is code base isn't so good, we clean it and eventually we can't clean it all, right? And for those of you that have this at work where you do these cleaning sprints, these cleaning iterations, we want to call them, these periods where you're allowed to actually clean the code, manage it, right? What happens immediately after you're done? As soon as you finish that cleaning sprint, that cleaning iteration, what happens next? New requirements, more things to do, right? And the business is chomping at the bit because you just spent two weeks delivering no. Oh, lovely, okay. So what is the winning strategy? And I already accidentally gave this up. Clean constantly, right? Don't make an intentional mess, monitor your, and I'm doing air quotes now around technical debt because what we're actually talking about is monitoring your cruft. But all of the tools that monitor cruft claim they're monitoring technical debt. You know how you monitor technical debt? You put it in the backlog and you schedule it. That's how you monitor technical debt. How you monitor cruft is different, right? Follow the Boy Scout rule. Do you guys know what that means in the code base? Follow the Boy Scout rule, yeah. Make it more cleaner, right? So basically the Boy Scout rule is, there's actually a couple of them, right? But the one that I'm referring to is leave the campground better than you found it, right? Same thing to code. Leave the code better than you found it, right? Add your feature, do that well. You know, write it cleanly. And while you're in there, go ahead and rename that variable from X to something meaningful, right? Go ahead and do a quick extraction of that one method, right? Do something that makes it a little bit better. If we all did this, if we all did the implementation as well as we could and we cleaned up one other thing, the code base over time gets better. And what's important about that actually, what's really interesting about that is, where does the code base get better? It gets better in the places where we're making the changes. It gets better in the places that have highest churn, which is where the risk is the highest, right? You may have really crafty, nasty code that's off in a corner somewhere that no one's touched for 10 years and it just does what it's supposed to do. Sure, it's ugly and it's not test covered and it's really scary to get in there and touch it, but if you never have to, don't worry about it, right? So this strategy keeps the code base clean where it needs to be clean, where it's most important that it's clean, right? And remember that quality is your responsibility and of course, don't ask permission to do your job correctly. This is what we are paid for, this is what we do, right? If we all do this well, we're good. So monitoring corrupt, I'm gonna go over this fairly quickly cause I wanna get to ability to have Q and A, right? There's a number of things that you can look at. There's a lot of different static analysis tools that you can run. I've got a few things that I actually like. All of them are fine, right? To some extent, but the ones that I really, if I'm trying to implement them at a client, there's certain things that I look at. Code coverage, so how much of the code is actually covered by our tests? I wanna be careful here. I actually don't care how much of the code is covered by tests in terms of like, oh, it should be 98.7% or you're not good people, right? No, what I care about is that you have coverage and that it is trending in the direction that you expect it to be, right? You may have a legacy code base that had no tests ever and so the best you're gonna get is 27% coverage because you're writing tests around the stuff that you're doing, that you're changing, right? And the rest of it just sits, never gets changed, it doesn't have tests. No big deal, 27% might be good coverage for you, right? Greenfield project, maybe something closer to like 90%. If you've got 100% test coverage, that's actually a smell for me, all right? Something's going on, I think somebody's playing games and I've actually seen this. I had a place that I'm a client that I was working with years ago and we started monitoring code coverage and someone in management decided like, oh, code coverage is good. Well, if code coverage is good, more code coverage is even better. And so sometime around May said, okay team, if you can get it to 100% code coverage by the end of the year, everyone gets a bonus, right? Now this is a legacy system. So there's a lot of stuff that we're not touching at all and it's not covered by tests. So the team goes along and they're working on stuff and the code coverage climbs up over the course of the year and in a healthy fashion, right? But come around November, so it's time for in the States Thanksgiving, right? Which is usually like a four day weekend, right? So it's time for Thanksgiving. Developer working on the code base, doesn't check in at the end of the day, you know, Jenkins picks it up, off it goes, build, runs the tests, da, da, da. We're at like 60 some percent code coverage. Okay, that's actually pretty good, great. And it's trending in the right direction. Monday, we come in, developer sits down, makes a small change, commits it before stand up, we're in stand up, build is running, test coverage. 100% test coverage. How did that happen? We had a check-in on Friday, it was 60 something percent. We have a check-in on Monday, it's 100% what's going on. The lead architect on the project decided that he would like to have the bonus and everybody else was working hard enough that they deserved to have the bonus. So over that four day weekend, he came in and he wrote one test that through reflection exercised everything in the application and asserted that true was equal to true. 100% test coverage, no failures, right? So it's not about the percentage, it's about the trend, right? Code complexity, cyclomatic complexity, ABC complexity, fundamentally code complexity is the number of logic branches in the code and there is a direct positive correlation between complexity and bugs. The higher the complexity, the more logic branches you have in the code, the more bugs you have. We can argue it all day long, statistically, there is a positive correlation between those two things. When you reduce the complexity, you reduce the bugs. Coupling, both afferent and efferent, right? Looking at what are the actual dependencies within the code base and there are better and better tools for this these days than there were in the past. Before I could get an object graph and I could see the dependencies but there was no quantification. I couldn't really get good things on count in that and these days there are. What I don't have in here is churn so I actually like to look at where's the code base changing which helps me understand what are the areas of the code base that I should be focused on most and then I have maintainability up here only because this is becoming a more common thing in how many of you are .NET? Okay, so .NET has had this for a while. There's this idea of a maintainability index and it basically is a heuristic that uses a bunch of these and then spits out a single number that tells you how maintainable your code is, right? And you're seeing this in other tools. Commercial tools have similar concepts around an A, B, C, D, F grade or something along those lines where you're getting kind of a single measure of quality which can be helpful, right? And I've already brought this up. Monitor trends, not points. The value at any given point in time is meaningless. Setting targets for these is going to give you the wrong behavior, right? Is it headed in the direction you expected to be headed in? Is it getting better? Is it staying the same? Is it getting worse? And there are going to be times. There are going to be times where you as a team along with your business make the decision that a dip in quality is acceptable in order for us to achieve something that we need to achieve, right? But if you're monitoring it and it goes the way you want it to, you know that you're going to get it back to at least level if not improving again, right? And if it goes down when you don't expect it that's a great time to have a conversation about what's going on. We weren't expecting this, right? So quick review, technical debt. It's a strategic decision that requires the business to actually be informed. It includes a payback plan. Cruft happens. It needs to be monitored and cleaned, right? It is not technical debt. And probably one of the most important points of this talk actually is never ask permission to do your job correctly. Thank you. Now bring this up so that you can, if you want for more, send a blank email to cto2 at sendyourslides.com. Subject line is technical debt, all one word. I will auto respond with a version of this slide deck, not this exact one, but a version of it, as well as links to all of the research. So I will give you Ward's Upsla paper. I will give you the technical debt quadrant and videos and basically everything that went into the creation of this, right?