[00:00:00] Good evening everyone. I hate that everyone is having such a good time, but we have a great presentation. The best part of my job is speaking to the most talented people in technology. By the way, I'm not sure that, you know, DevX is not actually an event. Company we're doing staffing and recruiting for technology. It that started from out of my passion of technology. I've been, I've been a software developer, I've been a CTO, and I saw that there are no technical recruiters in the firm market, and a developer's job is very different than an accountant, we all know that it's different challenges and different, different problems and um, and that's how Devex came to be. So if you know anyone that is hiring or you know anyone that is, um, looking for a job, send me a message, let me know, and I would love to help. [00:01:00] So one of the, one of the people that I met throughout the years had, it was Ben Schwartz, and we right away hit it off and he graciously agreed to come speak by the Devex meetup. He has a lot of interesting stuff to say, and the topic he chose for tonight is a controversial one. Um, or maybe not so controversial. We'll, we'll find out. It's meant to be a conversation, so if anyone wants to. Interrupt or have something to say. Feel free. And there is also going to be a q and A at the end. At the end. Okay. In the next 30 minutes or so, I wanna change how you think about tech debt. Not to excuse sloppiness, but to replace a vague emotional conversation with a practical one you can use with developers, leads and managers. And I'm gonna start with a sentence that you're not supposed to say out loud to a room full of developers. Tech debt is good, not all of it, not the [00:02:00] kind that's quietly rotting your systems, but the belief that tech debt is inherently bad is one of the most expensive misunderstandings in software. If you have zero tech debt, you are probably under shipping or you're accumulating it invisibly or you're calling it something else. Quick poll. Who here has been told we need to eliminate tech debt in the last year? Now keep those hands up if the same people demanded that you shipped faster. Exactly. Tech debt becomes the moral argument. Clean versus dirty. Good engineers versus bad engineers, and that framing is why teams drown. Let's fix that framing quick context so you know where this is coming from. Could you just define tech debt, what you're talking about? Oh, you'll hear it in the next three slides. What tech debt is, but typically technical debt is, ref is something that, uh, is used as [00:03:00] a detriment to your system. Old code typically is how it's referred to. I'm gonna change that definition a little bit. So, quick context, you know where this is coming from. I'm currently the CTO at Qubit Tech Cabinetry. I've been in CTO roles now for about 15 years. Started, uh, full stack development about 30 years ago. Everything I'm sharing now comes from decisions I've made and the consequences I've had to own. This isn't theory, it's scar tissue. So let's talk about, so here's the reframe that changed how I think about tech debt. I think about it like financial debt. Leverage is what you get immediately. Speed, learning, progress, getting to market, getting out of a hole. Interest is what you pay over time. Slower changes, more risk, more outages, more confusion, more work. So the question is isn't do we have debt? The question is what leverage are we buying and what [00:04:00] interest rate are we signing up for? We talk about limiting tech debt, like it's a realistic end state, but zero debt isn't the goal. Control is the goal because the world changes, requirements change, constraints change, people change, scale changes. The right design changes. Even rewrites don't eliminate debt. They refinance it into a new shape. So the goal is not purity. The goal is controlling what you owe. Why you owe it, what it's costing you, and what would make you pay it down if debt is inevitable. The real skill is knowing which debt helps you win, and which debt quietly destroys throughput. So there are two kinds of debt. I separate into two buckets. Good debt is explicit, it's time boxed. It has a payoff, it has a trigger that tells you when to repay it. Toxic debt is hidden. [00:05:00] It compounds. Nobody owns it. It surprises you at the worst possible time. I'll give you an example of each first, the good kind. When the workflow is evolving, code is the worst place to freeze it. You will hard code today's confusion into tomorrow's systems. Here's the trap we tell ourselves we're building the real solution. But what we're actually doing is locking down assumptions that haven't earned the right to be permanent yet. The team ships something that looks official, and suddenly every workaround becomes a new policy. In early stages, the highest value work is not perfect automation. It's discovering the stable path. Where do requests actually enter? Where do they stall, which exceptions are real and which are just noise? What does done mean to the business? So good tech. So good tech debt is a bridge. It's deliberate. It's, it's a [00:06:00] deliberately temporary layer that keeps the business moving while you learn. It creates visibility, forces consistency and turns chaos into data, and you'll only earn the right to automate once patterns repeat, and the edge cases stop changing every week. That's why the key question is not can we build it? It's, is the workflow stable enough that building it won't require a rewrite in 60 days? We were under pressure to automate parts of a production scheduling system, but the truth was the workflow was still evolving. Edge cases were showing up constantly. Exceptions, special handling, last minute changes. If we had rushed to build a full scheduling system, immediately, we would've hard coded the wrong process. We would've automated confusion. So we took on international, we took on intentional tech debt. We built a manual bridge in Google Sheets. The sheet tracked the production schedule as a single source of truth. It wasn't glamorous, [00:07:00] it definitely wasn't the final architecture, but it gave the business immediate visibility. It forced consistency around what was scheduled, what changed, and what was blocked. And here's the most important part. It let us observe the real process. At real volume before we automated it, we named that debt upfront. We documented what we were not building yet, and we set a repayment trigger. Once our proposed scheduling system matched about 90% of what the Google Sheet was doing in practice, that was our signal that the process was stable enough and volume justified automating the core. That bridge brought speed now clarity later, and it avoided a rewrite. Good debt has a payoff and a trigger. So what makes debt good? If you wanna take on debt intentionally, you need four rules. One, you gotta name it. If it isn't written down, it is [00:08:00] not managed. Two time box it. Debt without a time boundary turns into tradition. Three, tie it to a payoff. What leverage are you buying speed to market? Are you learning something? Survival of the company. Is it revenue? Fourth, define a trigger to repay it. This is the most part. This is the part that most teams skip. If you cannot state the trigger, it isn't good debt. It's just unpriced risk. A trigger can be stability or volume, revenue, a milestone or a known event, but it has to be something real. Now, let's talk about interest rates. Because not all debt costs the same. High interest debt is the stuff that taxes every future change or creates extra risk. Data, ambiguity, security gaps, brittle deployments, inconsistent definitions. Low interest [00:09:00] debt are things like style issues, minor duplication, refactor that don't unlock anything. One of mo, one of the most common failure, pat one, sorry. One of the most common failure patterns I see. Teams spend months paying down low interest debt because it's visible and annoying, while high interest debt quietly compounds and then explodes. Let's make this real turn to the person next to you. Name one piece of tech debt in your world with a high interest rate, not the annoying one, the one that taxes every change or creates real risk. Call 'em out. Let me hear so. Small. Good. What else? Who else has tech debt? Can't be the nun of tech. Debt basket printing. Good. Anyone else? Anyone brave enough to talk about their tech debt? Cons? Logs. Cons, logs. That's a good one. Beautiful black box. Un piped. Uh, Redis. [00:10:00] Saves and reads. Good. Those are all very good. Actually. Notice how none of those are code are, none of those are code style. That's the point. Sometimes the debt that kills you is not code at all. In a homegrown ERP, the most expensive tech that we had wasn't messy code. It was reporting that nobody trusted. The reoccurring fight was sales versus production, but the real issue was simpler. People didn't know what the reports were actually showing. One group thought sales booked orders. Another thought salesman units produced timing assumptions made it even worse. So the same report produced different interpretations depending on who was looking at it. The A, sorry. The ambiguity had a brutal interest rate. Meetings turned in debates instead of decisions, people created shadow spreadsheets. Engineering got dragged in constantly to explain numbers, [00:11:00] and every explanation made someone else less confident. So we treated it like debt instead of mystery. We clarified definitions in plain language. We signed ownership for each metric and we retired duplicate reports so that that was, so there was one canonical answer per question. The win wasn't prettier reporting. The win was trust. Faster decisions and ENG and engineering was no longer the referee, the highest interest debt was ambiguity, not code. Now how do you manage this intentionally without it becoming theater? Let's talk about the framework. Here's the simplest framework that I've found that actually survives real life. Classify price, pay track. If you do this consistently, the entire conversation changes. It stops being, we should clean this up [00:12:00] and becomes this debt costs us X at an interest rate of Y. And we're choosing to carry it until trigger Z first classify. Most teams, again, only talk about code debt. That's not where the biggest damage always is. I use five categories, product debt, missing capabilities or UX shortcuts, code debt design shortcuts, coupling duplication, data debt, unclear definitions, poor schemas, missing lineage ops, debt. Manual deployments, fragile environments, no runbooks people. Debt knowledge silos, undocumented systems, onboarding gaps. If you're a manager in this room, this is important. A lot of what feels like engineering is slow is actually ops data and people debt. Once [00:13:00] you classify it, you need to price it. Debt becomes manageable. When it becomes legible. Even a rough estimate works. There are three ways that I like to price it. Time tax. How many hours per week are wasted because of this change tax? How much slower does each feature become to, uh, to deploy it risk tax, probability times impact like outages, security incidents, bad decisions. If three engineers lose two hours a week to a brittle process, that's six hours a week. Over a quarter, that's 70 hours. That's multiple engineering weeks of capacity. That's not cleanup, that's throughput. The number is why pricing changes the conversation with leadership. Once debt has a price, it starts, it stops being a debate and becomes a decision.[00:14:00] Third is to track it. Debt must live in the same place as feature work. If debt is not in your system of record, it doesn't exist. And if it doesn't exist, it compounds. At minimum. A debt item should have a category, an interest rate, high, medium, or low, an owner a trigger to repay that debt. And it should be linked to the feature that incurred. Next is to pay it down strategically. Three. Three repayment strategies that I like to to use. Refactor as you go. Attach debt. Pay down to adjacent feature of work. Do small debt sprints, time boxed, focused, not endless, or quarter or quarterly initiatives when it's something that needs cross team coordination. The biggest mistake is treating debt as a separate, endless cleanup program. Pay down debt in the path of [00:15:00] value and prioriti and prioritize by interest rate. Finally, cadence. This is what makes it real weekly. You should review your top debt items by interest rate, not a hundred items, just the top ones monthly. Pay down one or two high interest items that are taxing every change. Quarterly retire an entire debt class. For example, this quarter we remove manual deploys. Or this quarter we fixed definition drift in reporting. So here's the close stop asking, how do we eliminate tech debt? The question sounds responsible, but it usually leads to two bad outcomes. Either it becomes a vague guilt trip with no plan. Or it turns into an endless cleanup campaign that competes with shipping and never actually finishes the steam. The team stays stuck arguing about, about priorities. Instead of making explicit trade offs, [00:16:00] start asking What debt are we choosing? What is the interest rate and what is the trigger to repay? 'cause that question forces clarity. It forces you to name what you're buying with that debt. It forces you to acknowledge what you're paying for it every week. And it force you to decide what would change your mind. And when you can answer it, tech debt stops being a complaint and becomes a strategy. Developers stop feeling like they're losing a purity contest. Lead stop being trapped between quality and deadlines. Managers stop hearing engineering wants to refactor and start hearing. This is a throughput and risk decision with a price tag. So if you take one thing from this talk, take this. Treat tech debt like a portfolio. Take it intentionally. Price the interest, put triggers on the biggest items, then pay down the high interest debt that's quietly stealing your ability to move fast. That's how you ship with leverage [00:17:00] today, without handing tomorrow a system that can't change. Thank you guys. I'm happy to take questions if anybody has any questions. Google Sheets just now. Good. So the question was how do you document tech debt? So I find that it depends on how you're documenting the rest of your requirements and the rest of what you're working with, right? So if you keep your requirements or your sprints or however you're doing your technical work in Google Sheets, then Google Sheets is fine. If you use Jira or clickup or something of that nature, that's where it should be. Treat it like a feature. Treat it like something that that needs to be addressed. Otherwise, you lose track of it. Exactly whatever platform you use to communicate, making it a different platform. So if you're using teams to communicate, you went on a loop, you went on a different, a different, a different sub component. And that's just for just set for that particular thing. 'cause it will, there's, there's always gonna be a list of stuff that you, that you can't do and you prioritize your tech that, on that. [00:18:00] How do you feel that Cursor is gonna, and similar tools are gonna change just how bad effect that is going to get? That's a great question. I so. Uh, cursor and other AI tools and things that are code generators, vibe, coding, I dunno if it's gonna, it, it's, it's, I don't think it's gonna generate any more tech Debt then exists today. It's just gonna make it easier to ignore that tech debt. So, uh, you, you know, create your, your code via AI and then you just assume that it's working and leave it there. And nobody understands what the prompts were or how you created this code or really what the code's doing because of however their naming conventions are set up. Or however you set up the, the code for that, for that thing. Um, especially also from a knowledge gap perspective, right? That's, that's the biggest issue that I find is it's more about knowledge gaps than anything else. Things in people's heads not documenting to me is the biggest form of teve you had in one of your slides, uh, schema lineage. What does that say? So in terms of where, what is the [00:19:00] history of that schema and where does it live across the stack? You also included there like, like there's a problem with the code base I'm working on where there you have these objects in the Redis and there's not necessarily a clear path of where they get initialized and you know what the hell is happening in between here and there Cost lot of bugs. That's, that's it on the head. That's exactly it. It's it's tech or something in your product that is causing a problem that either you don't know what it is because somebody. Built it five years ago and nobody documented it. Nobody understands it. Um, and the trick is two things. There's two things that can solve that kind of tech debt, right? It's either some sort of rewrite or documentation. Once you document it, once you get an understanding of what hap what's happening from that data layer or the way that the data's moving and it's documented now, it can be passed around. Now new developer can read that doc or whoever's dealing with this information knows what it is, and it's no longer a liability.[00:20:00] Thank you. Sure. A lot of what you mentioned, um, there's like two different parts. There's the development tech stack and then there's a lot of, it seems like missing business analysts, missing change management, missing a lot of that, which I found a lot of business owners think I'll just get a developer and tell them what I need and that will come the program, but it doesn't work like way. It's a great point, and I think I, my personal belief is a lot of tech that does not come from technical people. It comes from the non-technical people, whether it's business owners or, or I wanna, I don't wanna say ba, QA kind of stuff 'cause they actually have a better handle on what's, what's from a knowledge perspective, from a tech debt perspective. But it's, a lot of times it's business owners who don't document the process or create a new policy for the, for whatever they're trying to produce without any kind of reason or, or. Backstory around it, and then it just gets lost as, oh, we hard coded it this way. 'cause that's what Joel told us to do. And then, then [00:21:00] you're left. Always Joel. It's always Joel. Uh, a little, a little more, uh, real controversial question. I mean, it's the elephants in room with a lot of probably developers. AI in regards to tech debt in regards to spectrum. Will AI eliminate, uh, tech debt? Well, will you get to a point where all these things that you mentioned, where from the business will, will the AI LMM or or process take over that job where you'll have one master telling you, Hey, this is your inefficiency and either way of doing things, and they might even do your, your, your job where you'll have to oversee a check. Their will be more of a managerial perspective on it versus actual nuts and bolts of it. You see that that's happening? Is that coming? That's a good question. So we started talking about AI a little bit over here about in terms of, of code generation, but you've blown it up a little bit bigger. I think AI can definitely help in solving what I'll call code based tech debt. Right? It could definitely, [00:22:00] and I've done this with a couple different ais. You give it a, a huge code base and, and have it produce documentation for you. Um. And I find that that definitely helps. It doesn't get you all the way there. It may get you 80% of the way there, but it definitely can solve some of the unknown, the hidden things in code. But the ops cut part of tech that the, the why not, that's what I'm asking is if I can ask Gemini, um, a certain question that basically is the operation of a certain, let's say puling machine say, is soft water going to, they'll have all those factors that are, that are, that are in, in, in this, in this right schema of business to product. They'll break that down because why is that not coming next? So for something that it knows, yeah, for sure it can do that. The bigger problem is, and the modules of, of, of, of breaking down the process, if you can learn chess, it can learn this. It's just a matter of time. You have to feed it. So if you're in a company, let's say the company that I'm at now at Qubit Tech that has a 13-year-old code base and has [00:23:00] certain SOPs and processes that aren't documented and policies that were written. Because this is what the code did. AI is never gonna be able to help you with that. Why not? Because it doesn't know. No, it can read. It can't read Joel's mind. Right. Joel? The type that in that case is CEO. But I will tell you why. Why it can't, because Joel will figure out how Xco to see basically, and then we just work its way backwards. I don't think it can. I don't think it can. It can tell you what Z is. Doesn't know what's going on The shot. It doesn't know what sales are doing. I know your calling machine, the COVID machine is there, doesn't know what's going on because it doesn't know. It doesn't know what's in the CEO's head, he says, but that plus sales look all the different machines. Like, yeah, if you get AI to sit over the. A year. It has to have enough, enough of the data, [00:24:00] in my opinion, it has to have enough. It doesn't, it's not gonna have enough data to, to get to that point. Maybe listen, AI can change it the next year and, and you can have an AI that's sitting, you know, humanoid AI that's walking around your tech floor, your, your, your production floor, and you can figure that out. That's what's coming next. By the way, any other questions? Thank everybody. I really appreciate it. Thanks.