 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. In fact, the ability to pay back the debt depends on you writing code that is clean enough to be able to refactor as you come to understand the problem, clean enough to be able to refactor. 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? You don't even know what the hell it does, but you know it's wrong, 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 we can actually remove a bunch of that crap because we can kind of target what is it looking for. 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? And it became a huge, you know, a very popular thing. 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? You've been in this field for more than three years, you've had the experience where you've opened up a code file, have started to read through it and thought, what kind of an idiot wrote this? 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. So what ends up happening is when the cruft slows you down in the face of this expectation, the only thing you can do is write more cruft to try and keep up. 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?