B (3:45)

I hear what you're saying, but again it's all opinionated, it's all subjective because that team member, the team members, you're having the team at the time solve the problem for the way they were trying to solve it so another person can get hired your company and go, this is all technical debt now while the team that's currently there could be going, no, this is pretty good and it works for what we need to do and it solves all of our problems for now. You know, and we didn't, we didn't over engineer. It's very common problem for people to over engineer things, future proof things too much, in which case it takes too long to get them through analysis paralysis and get something out the door. It's a very fine line between trying to be productive and trying to future proof things.

A (4:28)

So, so is it really about preserving the ability to be agile in the face of future requirements?

B (4:35)

Oh yeah, right.

A (4:37)

And then you know, is so that, that, that I suppose is going to put you in a spot of how wide do you want to think about the, the world of possible future requirements? Right. Like, so in some senses that you can, you know, be prepared for certain amounts of change in future requirements. But every once in a while, you know, you get folks coming in and saying, you know, our business is now this. And then you'll be like, well, the thing that we built definitely isn't that. Right, like that. So is that tech debt or is that.

B (5:07)

Yeah, well, yeah. And you're relating it too, to our, the business that you're working with, that you're a part of the same business. And how do these items that people call technical debt, that I call innovation, are a part of that business? And there could be different goals there, conflicting goals. Let's say that the team decides they want to innovate on something. Technical debt on something, right. And that doesn't align to some kind of something a salesperson might have sold that doesn't exist yet, or another feature that's being highly requested. And so those things have to come together to figure out how you're going to prioritize and what are you going to work on. There could be things that kind of wipe you out for an entire quarter. That can happen too, where you just have to maintain things to get it up to speed. And that's not really debt. It's. It's. Libraries evolve, new versions of React come out. There's. There's things that happen. That's not debt.

A (6:03)

Let me, let me ask though. You know, there are objective measures of, you know, what we call tech debt, right. Sometimes you might call it something basically code complexity, right? Like, are we saying that we don't care about that?

B (6:16)

No, let's talk about. So we do care about it, but we phrase it in a way that makes teams remember it and contribute to it and help it out. So we are. Tim, I want to ask you a question. As soon as I'm done mentioning his here, I want some examples of what you think technical debt is. And maybe I'll help you understand my viewpoint. Maybe I can get something across there. But here, what I'm saying is that sometimes things get out of date. Mongo, for example, or Oracle or SQL Server or any of your databases, DynamoDB or anything like that, right. They eventually will become out of date. Is that debt or is that just maintenance? You know, that's just, that's not debt. That's. This software evolves over time, and so you have to maintain it over time. All right, so Tim, let's, let's. I think we should go into. What do you think are some examples of technical debt?

A (7:19)

Yeah, I think, I think we probably should focus on sort of the big and the small. Right. You know, and, and so, you know, when I mentioned something like code complexity, the easiest way to understand that is in the small. Right. Like you look at a function and you can, you know, objectively measure what's the complexity of this function and it can look at, you know, the number of nested loops and it'll come up with a number. And, you know, that could imply something that says here's how many unit tests you might need to satisfy that. And that could tell you things that, you know, this is basically harder, easy to deal with code. Right. And that's in the small. And that speaks to my ability to maintain that code without creating bugs into the future. Right, right. Perhaps my ability to understand that code, that, that sort of thing. The other side, on the bigger are things like, I chose to use an Oracle database that's relational or a postgres database that's relational. And changing circumstances over time mean well. My schema got too rigid. I might have been better with a NoSQL database. I might have been better with a document store. Those are probably trickier to call tech debt in the same sense. Right. Like, you know, it's so. I almost kind of look at it that you are trying to hedge against the future in the sense that, you know, I want to be thoughtful such that I can evolve over time because as you say, all software is about maintenance. Right. You know, and I think it's probably, you know, evident, but we should kind of point out we're, we're really, I think primarily speaking about software that's developed by teams of people, not software that's developed sort of by one person by themselves, or maybe even just one or two people by themselves. We're talking about, you know, software developed by teams that tends to last, you know, years probably. Right. Like, you know, I. There's probably some threshold of I need to do a task, and once I'm done, I'm done. And then you don't really care probably about things like tech bed.

B (9:13)

Yeah, so many things. So many. You know, sometimes people think that software is done. Software is never done. Obviously, if you just let a tool sit there and you don't maintain it, it will fall out of date. Now, Microsoft has done a great job making some of their older applications work in their operating system. Right. It doesn't fall out of date. That used to be a thing. Even some gaming systems have Allowed older games to play on the newer consoles.

A (9:40)

Right.

B (9:40)

Which is something that never existed when I was, you know, playing games in my younger years. That's a pretty amazing thing. So companies are aware that they have to kind of maintain older systems. Is that technical debt that, that game is five years old? No, that's the way it is now. Getting back to the points you made about, you know, maintaining understandable code. Sure. Database schema is getting too complex, or maybe you've chose the wrong architecture and like things that I mentioned about libraries getting out of date, you solve the problem for what you were confronted with at the time, maybe the scale that you were at and now you're at a different scale, or maybe you've run into another bottleneck. Right. And now you have to innovate above it. It's not debt, it's, your requirements have changed at that point. And so I, I, I'll, I'll stop now and I'll keep harping on it. I'll stop harping on this because I'm going to keep on saying the same thing and I don't want to do that. But I, hopefully you can understand where I'm coming from. Some of those technical.

A (10:42)

Right, right. So, you know, you keep kind of pointing to tech debt and maintenance as having a certain amount of equivalency. Right. And so, you know, when we think about handling tech debt, you know, in an enterprise, you know, in teams or teams of teams, how do you think about that? So do you have a, do you have a certain amount of, like we expect we're going to do 25% of our time into maintenance all the time. Right. Is that, you know, how do you think about that?

B (11:11)

It's a great, it's a great question. So how do you actually get teams to work on things where they're maintaining their code? Notice how I've already got you thinking about the word technical debt and now you're saying maintaining code. Right. So maybe I've just influenced you. Maybe some audience members out there also get influenced by that. At the end of this, Tim, you're probably going to stop calling it technical debt. Maybe we'll see at the enterprise level. So how do you get teams or maybe teams of teams, maybe a big company to think about technical debt and solve it continuously, like through maintenance. One thing that I've seen companies do is they'll dedicate a certain portion of their team or have even teams dedicated to this of maintaining code of technical debt. Again, I call it innovation. And, you know, it could be as Much as a little as 10% of their time, maybe 90% towards, let's call it feature work, and then 10% towards keeping the lights on. I've seen teams go up to 50% of the time where they're trying to balance between maintaining a system and adding new features. I've also seen it in a way where if you read team topologies or see anything from Manual Paez or anything like that, where they will actually have different types of teams in a company and they have different types of things that they work on. So a great example in developer experience is like a platform team, a team that builds, you know, container orchestration systems, or a team that does monitoring, or a team that does server upgrades. You know, this team, their whole job is the maintenance of the enterprise. And so they might be doing 90%, you know, maintenance work. Tech debt slash innovation at the enterprise level. So is. Is that kind of things that you're thinking about when you mentioned the enterprise idea there, Tim?

A (13:08)

I. I do think it's useful to probably still separate maintenance from tech debt. Right. So as you're kind of going through that, I was considering. All right, well, you know, what, what do we really mean? And, and I think almost, if you want to be snarky about it, is tech that the stuff that we don't know how to do, but maintenance is the stuff we do know how to do.

B (13:28)

Oh, okay. I like that. That's a tweet. That's an interesting thought.

A (13:36)

Like the bridge doesn't take us there. That's tech debt. Right. If it, if the bridge does take us there. Yeah, that's maintenance.

B (13:42)

Got it. Right. We just going to paint the bridge? Yeah, we're going to maybe resurface it. Right. But it still kind of works right where tech debt is. Nah, this biz bridge doesn't even go as far as we need now.

A (13:54)

So to sort of stick with the database, you know. All right, if I can keep adding, you know, more flyaway scripts to keep modifying my schema and do my thing, you know, I'm doing maintenance, but eventually I reach a point, it's like, well, this shouldn't have been relational at all. That's technically Right.

B (14:07)

We should have used Elastic or some other tool to, to solve this problem. Yeah, re architecture. Yeah, I get where you're going with that now too. But as it relates to the enterprise level here, what are your thoughts on how do you get teams kind of motivated to solve some of these problems?

A (14:26)

Well, I think, you know, you need to constantly work with your teams. Right. And you know, so I think this, this opens up to, I think a nice conversation about sort of roles and responsibilities where you want everybody to think the right amount ahead, right? So how far away is the horizon right. On things? And you could be too far or not far enough as you do that. So you don't want to. Classic examples of things like this is folks going and rolling their own ORM mechanism because they want to be able to swap from database to database for database to some other as yet invented technology. And so you could spend way more time than you should on creating an abstraction across abstractions. Right? But on the other hand, you know, as it, as it relates to, you know, general purpose maintenance in terms of, you know, keeping your libraries up to date as you can, you know, I, I think we've all experienced at this point, it's generally a better idea to try to stay current on, on libraries because it will pay off over the long run where you don't get into a, you know, a real situation where you can't get out of, can't get out of trouble. And so I think for me it's about encouraging my teams to be thoughtful about. All right, well, I'm, are we good for the next, you know, couple of months, six months? I don't know what the number is, but you know, I think generally this is one of those things like, like, like others, you know, when you see it, right. You know, so people can have a discussion. You can say to your, your partner on the team, be like, hey, what do you think I'm going to do this? And they might say, yeah, that makes sense to do that now. Or no, you know, we don't need to worry about that. That might never come up. I don't know, is that too vague?

B (16:06)

No, that, that makes, that makes sense to me. Pay attention to your teams. Ask them what's going on. Ask them what's going to come around the corner. God. Chrome gets updated how many times a month, right? And you have to stay, everyone's got to stay current with their Chrome version, right? Making sure that their, their website works on Chrome or iOS or Android or any other device, right? That's the multitude of devices out there. I mean, just think about what Netflix has to do with all devices that they support with smart TVs and, you know, different types of smart TV devices and all that stuff, right? So that's really hard to, to maintain and think about. There's the ways that you can solve that problem. But I think you're, I think you're absolutely right in that you kind of have to pay attention and mention the things that they have to do. Now you, Tim, you mentioned a couple times about there's, there's quantifiable things around developer, you know, around this idea of technical debt or innovation. So are there other metrics you mentioned cyclomatic complexity? I think. Were there other things that you, you think are quantifiable around technical debt?

A (17:19)

Yes, that's an interesting question. So I think we covered sigma complexity. You know, a common thing that folks would look at it would be sort of code coverage. Right. And, and so does low code coverage mean you have high technical debt? I, I would say it doesn't necessarily mean that you have high technical debt, but it definitely means you're at risk for technical debt in the sense that you won't know, you know, so you're so, so basically is probably a second order indicator of, you know, are you able to, you know, do maintenance and refactor your code on a reasonable basis. Right. So if you don't, so if you don't have coverage, you know, that's something, you know, I think a red flag for most folks. What other sort of things would, would sort of be out there? You know, I, I think, you know, go ahead.

B (18:08)

What about unit testing coverage?

A (18:10)

Right.

B (18:10)

That's the first thing. If someone's going to hit a code base and they don't see the testing coverage, it could be at 10% or 0%, 50%. Right. And people can say, well, my threshold is I like 80. Well, I like 90. Right. And then it becomes objective again, sorry, subjective again. It's like, you know, people, it depends on the teammates you have at the time with the brain power or the knowledge of the experience that that person had to say what is technical debt? If you're talking about complexity or architecture. So, yeah, so I think maybe unit testing coverage might be another one people might bring up.

A (18:45)

So are you maybe implying then that, you know, a team kind of ends up with sort of a, their own kind of cultural definition, like, or like a local definition of tech debt.

B (18:55)

Very good. Thank you for crystallizing my own thought there. Yes, I think I am saying that teams decide, the people that they're at the time decide what is technical debt. Yes.

A (19:07)

So if you've got to manage one of these teams, how do you feel good that, that they have in fact done that?

B (19:16)

Well, it's against my, it's your brain power. It's my brain power too, that we're saying what from our experience is technical Debt versus what we've seen in other companies or other places we've worked or things that we've seen. This code. And for me it comes down to kind of two things like I've mentioned. One is that whenever we touch this piece of code, it breaks.

A (19:40)

Right.

B (19:41)

Or there's a problem with it. Right. That one really hurts a team's morale and productivity and people say, oh, I don't want to touch that. Right. So that, that might be an idea for refactoring, which some people might consider technical debt. And the other one is the other things I mentioned is like just pure maintenance. Like things just naturally decay over time through, you know, entropy and you have to kind of reassemble them together so that they all work. So just things I was thinking about.

A (20:13)

Yeah, well, you know, I think the having kind of a coherent process for which the way, you know, the team works on the code is kind of a key.

B (20:23)

Right.

A (20:23)

So if your team has a robust pull request process, where during that process it's evident that team members are providing useful and valuable feedback to each other, those are probably good indicators that people are thinking about tech debt. Right. So, you know, sort of following from that, you know, when, well, maybe this is a question. So, so, so say a team member comes to you and says, hey, you know, listen, you know, you know, the such and such module, that we're going to be in trouble, but we, we've really got to kind of rewrite this. Like how, how, how is that viewed for you basically on your team maybe as like a team member who wants to, or suggests engaging in some refactoring of tech debt or as a, as a leader that's going to sort of agree to the, to the cost of doing so.

B (21:13)

Well, I would love to know how you handle this too. I'm just going to briefly say how I think about this is you have to give them the opening to do it. So you, you have to do, depending on how you kind of schedule your work, if you're using more of a Kanban system or if you're using a quarterly planning process or however your intake comes in, there has to be a pipeline, an intake process for that to become surfaced and visible so that you can plan just, you know, at least a sprint or two ahead so that, you know, okay, this one's going to come in. This one might take a long time to do. How is this going to impact all the other things that we have to do as a team? So my idea would be give the teams an intake process for that to surf, have some type of meeting, maybe it's weekly, maybe it's bi weekly, where you talk about exactly this, like what are our innovations or technical debt items that we need to do in the upcoming quarters? How do you handle it, Tim? How do you kind of surface these things and deal with that situation?

A (22:10)

I think what you're describing makes sense. I think I would probably add. So, you know, in addition to you want to have team members feel like they're empowered to actually make some of these decisions themselves. Right. In the sense that I think that creates ownership. Creating ownership I think reduces technical debt because people feel, you know, this is mine, it should be good. Right. But I think what you also need to do sort of from, from, from a leadership side of this and the leadership could be the manager, it could be senior technical folks on the team, is ensure that you're doing everything you can to avoid sort of high risk, high reward scenarios and sort of. What I mean by that is that you want to be mindful of folks that say, all right, I'm going to, I'm going to fix this system. It's going to take me six months and at the end of six months it's going to be awesome. Right. I think what you want to do is create scenarios where there are multiple ways to succeed and that success is iterative. And so I, you know, in terms of signing off on big major rewrites or refactors to self protect that you're looking for. Right. Well, how can you chip away at what could you give me, you know, this sprint? What could you do the next sprint such that, you know, all the usual agile stuff kicks in so that you can adjust as necessary.

B (23:23)

Yeah, I like that process too. Now a couple times too we mentioned about, hey listen, we have an architecture that we didn't like and now we want to do this new architecture. You mentioned the bridge thing. What are your thoughts on do it right the first time? So we always talk about this like, oh, you know, we, we have to, we have to make sure that we do this right the first time and that everything is perfect and it's all going to work out the way that we expect it to and there's going to be no, no debt around this item. What are your thoughts in those words? Do it right the first time as it relates to development and developer experience.

A (24:03)

Yeah, I think, you know, the definition of that can vary for a lot of different folks and it's probably important again from a team and cultural dynamic to understand region for each of our Teams to understand what it means to them. Okay. Because I, I think, and maybe this is where you're going with this. It's very easy to get carried away with this. Okay. And so however, there should be certain kind of norms in place that say, listen, these are things that are required. So for example, like if, if you're doing it right the first time does mean you have to have good tests and you have to have kind of, you know, quality code coverage. And if you're a team that uses things like cyclomatic complexity or use a, you know, a score from something like a sonar cube that says, this is what the quality of my code is, every team needs to understand what their sort of thresholds for. You know, it's got to be at least this good. Right. And, but we also do need to be kind of mindful of the perfection camp in this because you know that, that, that almost definitely can't be worth the time. Right?

B (25:06)

Yeah. Diminishing returns. Right. Eventually you're going to see the point where it's like, okay, do we add this extra 10% because it's going to take us six more months to do this.

A (25:14)

Right, right, right. Does that.

B (25:17)

Yeah, yeah. Those, those are my thoughts around that. Like, you have to choose when you're, when you're done. What I was thinking was around, there is no such thing as do it right the first time. And here's how I think about this, is that just like any kind of continuous improvement process, even if you do something that's very good and lasts a very long time, it's not going to last forever. So just because you've done it right means you've done it right for the problem you're trying to solve. Right now your business could scale to from like 100 customers to a thousand customers to 10,000 customers in a year. And though you've done it right at that time, it's now no longer right. Like imagine a single tenant system to a multi tenant system. Maybe there's something there that doesn't scale. And though you felt like this was perfect code, it's because the people at the time that solved the problem said that this is right. This is what I'm trying. Yeah, yeah.

A (26:18)

I think I would kind of relate it this way. You know, the best developers that I have worked with are generally pretty good at saying, I can live with this code right now. Right. You know, it may not be everything that it would, that I could imagine it to be, but it's good enough for now. Right. And, and I Say that because I think, you know, really good developers know that there's always ways to make things better, but they have that handle on this is good enough for now. Because I think what they mean when they say something like that is that they think that, all right, well, if I have to come back to this in the future, there's enough there there that I can work with it, I can evolve it, I can, I can kind of make forward progress. But, you know, this is where I stop on it. And that oftentimes is a sign, I think, of a good developer. Okay. And, you know, maybe it's somewhat of a corollary to that because this is also sort of, you know, writing code is a learning process. And throughout that learning process, you learn things such that if you had to go and do it again, you would do it differently. So, so, you know, so what I mean by that is that these developers are, you know, generally of the mindset of. All right, well, I'm never quite happy with, with, with, with what my code was, because if I had to start again, I know it would be better on that. You know, is that, that riding kind

B (27:37)

of the wave, sort of exactly where I'm going. Right, so you solved it the first time. It's like your first draft, right? Okay. You know, your second draft's gonna be better, and you know, your third draft's gonna be better than that and fourth draft you. Because that's continuous improvement.

A (27:50)

Right?

B (27:50)

So, and also with developers, you know, we talk about developers looking back at their old code and they go, this isn't, this isn't good code. And I think all developers should be thinking that way when they look back at their old code, because that means they've gotten better at coding, they understand more patterns and practices and things, ways to simplify things. Now, if you've been doing this for 20 or 30 years and you've been using Java for that long, maybe you've gotten to the point, right? Because all the books have been written on Java, it seems, and Java is the way Java is. But when you come to new languages and as things evolve and get better and there's different frameworks, things will change more frequently. Like React and Angular and all those other tools, right? Especially on JavaScript environment, there's always better ways to write JavaScript. It seems like there's no one book on how to write, write JavaScript because there's 10 different ways, 10 different ways to do it, all these languages. But JavaScript keeps on evolving over time. So, yeah, this, this comes to that Idea that, you know, along with six months ago, my code wasn't very good with people not understanding a code base. And so they think it's bad. So if they didn't write it, they think this is bad. So if I did the first time, and it's got to evolve over time. Oh, I must have to refactor this. And this is where we get to, to those ideas over cleverness, clever code and clever code to what you had mentioned earlier, Tim, around technical debt could be hard to maintain. So have you seen this in the past and how has it affected your teams when you've had maybe clever code or overly complex code, did people say it was bad or did they say, no, this is really future proof? Like how. How have you handled the clarity over the Clari cleverness thing?

A (29:39)

Yeah, so I think at this point it's pretty widely understood that most code is maintained, not written. Right. So you only write it sort of the first time once, and then you maintain it forever and ever. And, and, and I think we all have, throughout our careers, at this point, experienced code where when you look at it, it's like, wow, I never expected this to, to still be running in production on that. And so with that in mind, I think people really need to lean towards clarity. Right. And I think, you know, I'm speaking for myself. I have definitely, I can think back to some specific examples where you've been burned by cleverness in the sense that, like, you, you know, you're working, you're working, working, you realize, oh, shoot, if I just do this this really clever way, this basically makes all this code go away, or it simplifies that kind of things, but then have had to either experience coming back to that code yourself after a few months or another team member sort of scratching their head and saying what's really going on here? And so because of that, clarity tends to be really kind of key on things. But I don't think that there's really a measure for what that is. I'm not aware of any particular measurement on that. Have you seen anything like that

B (30:57)

number of defects arising from certain sections of the code base. There's also something called code churn that I've seen out there. So this is, you know, a tool monitoring your system and it will understand how often a file gets changed. You know, and if your file is large, like thousands of lines, there's more of a likelihood that there can be complexity in that file, in which case these systems would pick it up, be like, well, listen, this code files churn In a lot, there might be some kind of, you know, cleverness or something else going on here or just pure not breaking it up. Right. That could happen. So there are, there's, there's some companies that will, that will measure some of those things for you.

A (31:40)

Yeah.

B (31:41)

So

A (31:45)

how do you, how do you keep people. Well, I'm thinking sort of that example of clever. I almost kind of have a counterexample of like, all right, if code is too clever, do people just sort of avoid it? Right. And so, you know, with that in mind, how do you motivate people to sort of stay on top of, you know, their, their maintenance or their tech debt?

B (32:03)

It's, it's, it's, again, it's, I, I, I believe it's creating the window for people to talk about it and it not being a bad thing, I think, because, because people don't want to bring up a bad thing to their boss, you know, or, or their teammates. Like, oh, some people have no problem saying this is crap, right. But, but other folks, they don't want to say things are wrong. And so if you call it an innovation, people are more likely to come and talk about it and want to do it. All right, Tim, I have a couple, maybe, maybe we have time for a couple more questions here.

A (32:35)

Okay.

B (32:35)

I wanted to touch on this one because I thought it was really interesting. Are there the choice of language, does that make a difference in technical debt, in your opinion?

A (32:47)

I think generally it probably does. I, I, I think languages such as Java are a good example of boring, perhaps, or, or, you know, the types of things that people complain about in terms of things like boilerplate and some of that kind of repetitive nature in Java. I think that makes them on a good team, less prone to tech debt in the sense that the odds of, you know, two different developers creating a similar solution to the same problem in Java are reasonably high as compared to other languages. You know, like you mentioned your JavaScript frameworks, and frankly, you know, I think this is probably what you're getting at. Oftentimes when people are programming in JavaScript, they're not programming in JavaScript, they're programming in a framework. So unless you happen to be familiar with that framework, it may be completely, it may as well be a different language. Right. Whereas with Java, things are reasonably the same. If you and I solve a problem in Java, things are more or less the same. Or even when it is frameworks, I would say in Java, you know, realistically speaking, in Java, the framework is spring, right? That people, that people are Using. Right. And then that runs the gamut, you know, up until, you know, folks using more exotic languages like, you know, you find a team that's decided to write their code base in Scala that, you know, not only is a. Probably more of a dense language in the sense that you can get more, done with less, but then you're also running square into. Does everybody on your team have the level of familiarity with that technology to be successfully navigating their maintenance? What about you?

B (34:23)

I think that's. I think. I think you put it very well. Very similar way to that. I. I would have answered that question, too. All right, Tim, we probably have time for one more here. Last question. And this is. This may be controversial. It's interesting thought. Does responsibility vary based on the level of the team member, I. E. Do junior members create technical debt and senior members fix it?

A (34:51)

Yeah, I suspect we've probably all seen examples and counter examples of all of this. Right. You know, and so I think we've probably worked on teams where there's senior members who are, you know, evidently very good coders, where people look at their code and think to themselves, wow, that's like a. That's a role model for me. I wish I could. I wish I could have done that as well as Chuck did the first time. Right. And that's really good because then you kind of have people learn, and as long as Chuck's a good mentor and not a jerk, then things go well.

B (35:23)

Hey, I don't know what you're talking about, but.

A (35:25)

Right. I think, I think on the other hand, you can also have junior folks that kind of come in perhaps without preconceived notions or without the baggage of, you know, we tried that once in 2003 and it didn't work, and so we'll never do it again. So I think you can kind of get it both ways. So I would basically probably roll it together by saying maintenance. Tech debt is sort of like farming. Right. Like, you've got to kind of like 10, 10 the field, tend the crops, you know, maintain the tools, and that gets the culture where everybody should get to kind of play a role in it. Right. Like, I think you got to get to a place where people don't view it as someone else's job to sort of, you know, alleviate the tech debt.

B (36:09)

Got it. Yeah, I agree. It's got to be team's job and team's job to figure these things out. All software development is a team sport.

A (36:18)

Yeah.

B (36:18)

All right. Well, I thought that was a great conversation, Tim. Have I switched your idea around saying technical debt yet or you're still. You're still a tech debt person.

A (36:31)

I think there's probably more discussion that could be had. But I like what you're going, Chuck.

B (36:34)

So I didn't win.

A (36:36)

We'll leave it at that. How about that?

B (36:37)

Maybe next time I'm going to convince start calling innovation instead of debt.

A (36:42)

All right.

B (36:42)

All right, everyone. I hope you enjoyed the podcast. Please make sure to rate us and leave a comment. Thank you so much. Thanks so much, Tim. Have a great Chuck.

A (36:50)

See you next time.