Continuous Refinancing of Your Tech Debt with Rachel Stephens of Redmonk

Episode 132 · 47:46 · SRT · archive.org · all Tanzu Talk

Welcome back, folks. This week, I sat down with Rachel Stevens of Red Monk, where we explored the edges of the analogy around technical debt. As two people with backgrounds in finance, we had quite a bit of fun, dare I say, too much fun, talking about where the analogy breaks down, but where we could also actually extract more insight by pushing further into the boundaries around what this finance construct is all about. Can we learn more? Can we understand more? Can we make better decisions? Those are all the things that we talked about this week. And you can also find some more resources in the show notes, slides to the presentation on this topic I presented back in May, in the show notes published on Pivotal.io, where you can also find a discount code for SpringOne Platform happening in Austin, Texas this coming October. So we hope to see you there, and I hope you enjoy the rest of this show. I was talking to my dad about the talk that I gave at Glucon, and it's like, oh, hey, dad. Yeah, I gave this talk. It was on trading derivatives of tech debt, and I was explaining what I kind of defined as tech debt. This is the problem when you have an accounting professor as a dad. He's like, Tormain, what you described really sounds more like a deferred cost. It's like, but dad, you can't trade derivatives on deferred costs, and that's so unsexy. How are we going to get anyone interested in wanting to talk about this if it's a deferred cost? Like, no one even knows what that means. So, you know, I think we've, I kind of got around that it was like, it was clearly an analogy. Then, okay, fine, if it helps people.

But I just kind of loved that it was like, well, actually, Dormain, going full professor on me. That's 100% delightful. Yes. And I thought that my guest this week, guest, would you like to introduce yourself? Hi, I'm Rachel Stevens with Redbunk. I thought you would appreciate that one, given that you pointed out a number of the flaws in the tech debt analogy. And, like, I was just reviewing that post for my prep for Glucon, but now I'm like, it wasn't last year. I mean, it was a couple years ago now, right, that you wrote that? 2017. Okay. Yeah. Okay. So now you've had, you know, some more time to kind of marinate on it. But, yeah, you pointed out this analogy has a bunch of flaws. And so, and then recently, I think I've been hearing lots of people talking about, it's like, you know, I listened to a podcast with some other folks who were just like, we've got to stop calling it that because it's demoralizing. And we end up with these tech debt boards that, like, you know, we're never actually working on, and it just demotivates people. And I sort of feel like, hmm, I think the analogy might be being misused in a couple of different ways here. Oh, that's interesting. So I feel like there are, like you said, a couple facets there. I think that one of the things that's important about using analogy is understanding how the party that you're trying to make the analogy to is likely to understand that. And that was kind of where my post came from, was trying to kind of talk. So my background is actually in finance. That's how I started my career. And so coming into the tech world and kind of getting this view of tech debt from the technical perspective, but also having this view of debt from a finance perspective. Sometimes the things that people thought were really scary to a finance mind don't necessarily set off all of the alarm bells that people think that they're setting off when they say interesting.

It's like, yeah, the finance world is used to interesting. That's something that everyone is used to. The world runs on leverage, and people usually, when we do debt, it's something where it's a known amount borrowed for a known timeline. And generally, at a known interest rate, it's contractual. It's not that scary. It's just trying to make a known, understood, like kind of wise choice on how we want to use our resources now versus in the future. And sometimes that metaphor, when it comes to tech debt, can fall a little bit short because we don't have a lot of those things as knowns. And so, like, what we're trying to convey is risk, and we're using the term debt to try to convey that. And sometimes maybe we don't quite get our point across when we're talking about, like, there's going to be this future unknown state that we're going to have to work to fix. We don't necessarily know what that's going to be, when we're going to have to do it, how long we can run on the stack as we've built it. And so, I think that some parts of the analogy don't quite translate. But I also don't think it should be demoralizing because I think that – so, I'm going to turn it back to you because one of your parts of your talk that I loved the most was when you talked about how all code is debt and how debt really powers not only business but also all of IT. So, I'm going to turn it back to you because that's where I think that this is where it should go next. Yeah. Well, I mean, it's – I guess it's sort of revisiting the analogy and to your point where it's kind of gotten – folks have gotten wrapped around the axle around the wrong points. And, like, yeah, risk is really the issue we're trying to convey. And so, looking at all code as the – maybe the principle, if you will, right, of the tech debt.

And this is coming from listening to, you know, folks like Charity Majors, and she's talked a lot about how some of the best engineers she's worked with work really hard to not write code. And listening to even some of our customers who really extol the value of being able to just strip out as much boilerplate code as possible and just pare it down so that it's simpler to work with. And, to me, it's sort of, like, looking at it that way, then coming back to your list of, like, here's three knowns that normally when you're dealing with debt, you're dealing with a known amount, a known timeline, and a known interest rate. It's like, well, if you consider all of your code, the principle debt, then you know the amount. So, actually, we do have a known amount. And then you can kind of go out and look at how many lines of code do we have. I mean, is it really useful to kind of take that inventory? I'm not sure. But it's more of just a philosophical mindset. And then to your point of what's really challenging is thinking about, like, the risk. And then if you come back to, well, most of the time we have a known interest rate, but there's, in the derivatives world, is where you're dealing with the risk around changing interest rates. And managing that risk is actually a thing, because there's a lot of, you know, the whole world of, like, credit default swaps. And it's like, well, that's, well, credit default swaps are really what, you're talking about a default risk. And then to bring it back to, like, more consumer-friendly terms is thinking about the adjustable rate mortgages and stuff that folks, like, really got, a lot of folks got turned into, you know, upside down underwater mortgage situations for their homes with an adjustable rate mortgage.

Because that known interest rate wasn't actually known. And so those do exist in the debt world. And I think that is kind of maybe a way to think about tech debt is you never really have, like, a contractual interest rate. What you have is, you know, some ways to understand, like, what, if you've got a generally low interest rate, but also where you might have some potential ballooning interest rate risk. So to your point of, it's the risk that's actually what's scary to the business. And I think that's also, it kind of helps you get comfortable with the fact that, hey, you know, we're not going to get rid of all of our code. Like, that's not the objective here. The objective is to make sure that we've got manageable interest payments and that we're thinking about how we're managing the risk of, could some of these interest payments change on us? And I think I didn't really get to spend as much time as I would have wanted to. I owe the organizers a write-up of this. But some of the things that I've seen folks do that seem to help them bring those interest rates sort of under control, things like test coverage and having good CICD pipelines and really thinking about automating their full path to production, instrumenting that, that's where you can bring a lot of uncertainty and, you know, risk out of the picture and de-risk the code base that you do have. Yeah, so that's sort of, I think, what I was trying to get at by calling all the code tech debt. You embrace it just the same way you do on the business side. And then you start to think about, you know, those interest payments and what interest rate you're looking at. Did we ever actually introduce where you did your talk?

No, I think I maybe briefly mentioned Glucon and prepping for Glucon. So this was at Glucon in the end of May. So I'm not sure when this podcast will go out. But it was a delightful talk. And Dorma Mane's talk was called Can We Trade Derivatives on Technical Debt? And it was such a fantastic talk. It was like all my favorite things all at once. And one of the things that I wrote down in my notes while you were talking, so you had the slide that's like all code is technical debt. And my note on that is that means that you're in a perpetual state of refinancing. You're never going to get to the point where you get to pay. Like if you're viewing it as all code is tech debt, then you never get to the point where you have zero debt. Like you're never going to live in a world in which you have no liabilities. You will always have liabilities. You just get the opportunity over time to refinance and kind of work on coming up with different terms of your loan, I guess, is a good way to think of it. Yeah. I mean, if you've looked at pretty much any company out there, they all have debt in place, right? I mean, the reason a balance sheet exists is to like make sure you're accounting for your liabilities, which, of course, to my dad's point, a deferred cost is a liability that's not technically debt. But, you know, even if it's something just like an overnight credit facility, I mean, there's all kinds of structures in place that are essentially like, listen, you're borrowing something. And I do think that there is something to my dad's point of like, one thing you're missing, and I pointed this out in my talk as well, is we have to understand who the borrower is and who the lender is. Like we're often talking about tech debt from a very borrower-centric perspective. But if you want to have a conversation about derivatives, you have to understand who the lender is. And this is another place where the analogy kind of breaks down.

And maybe this is also where, you know, we should say like, listen, you got to, you can either pick a different finance analogy, or you just, you just got to figure out something else. Maybe we should do a quick segue into kind of talking about how viabilities have offsetting assets elsewhere or equities elsewhere. And maybe a quick definition of what a derivative is for people. Yes. Wow, you're really good at like teeing up these questions. Usually I'm like, I'm supposed to be asking you the questions. Yeah, so on the balance sheet, you've got a lot of different items there. And a lot of assets and liabilities are kind of offsetting each other. And, you know, they have a natural course between flowing from living as an asset to then a liability, even when maybe there's not even a cash flow event. So I don't know if that's kind of what you're getting at with that kind of question. Yeah, I think it just makes sense to make sure that people understand, like when you're saying understanding who the lender is. So like, for me, as a borrower of something, that's a liability for me. But whoever lent me that money, that's an asset for them. Oh, yeah, right. So like the accounts receivable in a way, right? So, yeah. So that's a good point. And this is honestly, this is where I kind of got stuck. And it was chatting with your husband the night before my talk that crystallized that even though I don't have the answer to this, it's raising an interesting question for people to explore on their own. And so it was, he gave me some validation that like, yes, that is an important question because maybe we aren't thinking about that correctly.

And we're writing checks to ourselves and it doesn't make sense. And so I think my first gut instinct is that it's the business side that's, you know, sort of lending you because they're using that code as an asset to your point of that offset. I mean, what else do you see in terms of the potential relationship between, you know, the either the borrower and the lender or what the offsetting assets would be if all code is should be sort of considered technical debt? This is not a perfect analogy, but this is another one that I wrote down in my notes while you were talking on stage. And it was 401k loan, question mark. Are you borrowing from yourself in the future? Like, is this, are you taking away things that are kind of supposed to help your future self that you've set aside for your future self and you're going to take them now? So that was kind of the thought that I had there is a possible counterparty. But I think many people would argue that that's not a super functional counterparty. And if we're trying to argue that debt is a necessary part of life, I'm worried that that analogy might scare people. I was also going to say, if you can explain how a 401k loan even works, you're way ahead of the game. Those always seem really convoluted. And that's maybe part of the problem. So it's, I see where you're going with that as a potential analogy of like where things might be getting corrupted isn't the right word. That's, that sounds too nefarious, but, you know, questionable in terms of whether this makes sense and is the right thing to do. You also asked about the, well, go ahead. Oh, I was going to say the one part of your analogy that I loved is you, before you were kind of going into the different tranches of interests. And I loved comparing that to kind of the Martin Fowler's view of like reckless to prudent versus deliberate and inadvertent debt.

And I think that that's a really powerful part of how we could think about technical debt. And I think, I think that's a part of the metaphor that does very well. Yeah. And, and that, that's sort of comes back to your, your other question about defining the, the different types of derivatives. Cause derivatives are, they're, they're used a lot in the finance world. It's actually a massive market, but they're not typically done by, you know, consumers. It's a really institutional level, um, you know, asset class, I guess you would say. Uh, so derivatives are like, there's a couple of different types, but at their most basic, it's just kind of an agreement, usually it's a contract of some kind. And there's usually a sort of the asset, the underlying asset in question. Um, and so, you know, the, the buyer of this contract is entitled to, you know, some amount of this underlying asset at some price or some interest rate, right? Since interest rates are usually that the, the fluctuating metric. And then there's usually a date associated with it. So if it's an agreement, it's not in perpetuity. So options are probably the thing that are the most familiar to your kind of average consumer since, you know, you can, as a consumer trader, you can get an options account. Um, and they're an option is, you know, those contracts are usually written in, I think up to nine month. Time spans and, you know, you're either buying or selling a, a, a put, um, or gosh, I'm blanking on the other one, but basically it's like, okay. Um, but yeah, puts in calls. It's like, so I can either, um, but I buy the right to sell this stock, uh, for this price.

Um, and so why would you want to do that? Right. If you own shares in some company and you already stay, you inherently stand to gain if the shares go up. So how do you help yourself, um, you hedge that by figuring out a way to gain if the shares go down? Um, and so there's a couple of different ways you could do that where you could sell, uh, the, the right for someone else to buy the stock if it goes to a certain price. And then you're sort of just collecting, you know, you're, you're getting, um, you're, you're yielding some income on that share. You don't really plan to sell it, but you know, if, if it hits that strike price, you are obligated to do that. Um, but you get to sort of make a little bit of other income on the side, or you lock in your ability to sell, you know, let's say you've got something and it's trading at a hundred dollars a share. And you want to be able to lock in the ability to sell it at $80 a share, just in case the thing craters down to 50 bucks a share. Um, so you can buy a put, uh, for example, and then you're able to, you know, you're, you, the, the person on the other side of that agreement is obligated to purchase that $80 a share. Um, and then there's a whole market around that, right? Those contracts themselves become traded as the underlying asset moves, say closer or further from $80. Those contracts become more or less valuable. Um, and so the contracts themselves have a price. So that's like, uh, you know, a classic form of a derivative and you can replace the stock price with something like an interest rate. So if I have a loan, I'm already standing to gain if the person who has borrowed this money from me is making their interest payments.

Like I already stand to gain from that, right? Like I lent them the money and, you know, part of that agreement is they're going to pay me with this interest, but what happens if they default? So how do you offset your risk that they default is you enter into a derivative agreement where someone else is going to, uh, have to pay that, right? Or, you know, you, you, you can sell part of that interest rate, right? That you're picking up in the meantime. So there's different styles of derivatives you can do there. Um, or if the interest rate might fluctuate and you want to convert something that's fluctuating into something that's stable, right? That's a, and like an interest swap. So those, those are just agreements between two parties. And then there's a market for those agreements. Um, now there's this other kind, which is sort of like the, where the collateralized debt obligations, which was another, uh, one of the many cast of characters that showed up during the financial crisis of the 2008 ish era. Um, you know, the, I feel like the, the collective American public got immediately exposed to a bunch of derivative terms and generally agreed that it was, uh, uh, complicated and scary. Um, but collateralized debt obligation is really where, okay, we're, we're pulling together, um, a lot of, in this case, talking about mortgages, right? So the collateral is the house on the mortgage and pulling those together and then trying, like cutting those into tranches. And there's really the, the prime loans are in one tranche and then they kind of get progressively less prime. And then you're in your, your subprime territory. Um, and the subprime is really just like, those are more likely to default. Um, and so starting to think about, okay, if you're, if all of your code is debt, but you've got different applications and you've got different profiles and essentially different risk profiles on these different code bases.

So coming back to your point of like, what really matters to the business is the risk on them. And what if you, if you pull that together and start to analyze it as what are your different tranches of tech debt? Where do you have, uh, good sort of high quality loans out there, which is your high quality tech debt, uh, low likelihood of default versus where do you have stuff that's pretty risky, right? It's going to, it could blow up in your face at any minute, right? You could have a whole bunch of that debt sort of default on you, if you will. Um, which could mean like, it's impossible to change, right? That, that code is basically completely unchangeable. And then you're, you're just really stuck with it out there. Gotcha. So like what I love about derivatives is that I think, like you've said, a lot of the audience here is probably familiar with derivatives blowing up the worldwide economy. Which is unfortunate because one of the main uses of derivatives is to help hedge risk and for people to kind of make informed bets about how things are going. And so one of the things that I was playing around with, and this is totally a half-baked idea. So we're going to have to back this one around a little bit. Oh boy. So if you're thinking about ways to hedge risk, and then you're thinking about, um, kind of, so if we're trying to think of someone who's helping us hedge our risk, and someone who's like a third party, who's maybe going to take a stake in our code base, would that be someone like a pivotal or like an open source platform like a Kubernetes that takes away a lot of like the risk? If I had to build everything myself, um, and then try to start, um, you know, making that just a little bit more accessible, a little bit less, um, all on me and more abstracted away.

Like, is it, is, is that subtraction, I guess is the question. Hmm. Hmm. Well, I mean, I think that what's interesting is maybe not so much pivotal, but I think collectively as an industry, if you go back 15, 20 years when, uh, someone declared that the world is flat. And everyone was frantically, uh, offshoring and simultaneously outsourcing a lot of their IT and code development at the same time. And in that case, they were introducing, I mean, and this still goes on today, um, they were introducing like this third party that was, um, in theory going to de-risk like the, the whole IT operation landscape. I mean, including development and all, uh, and I remember distinctly covering EDS, uh, back in the day. And they had this, I think it was NMCI, the Navy Marine. It was basically like an internet, uh, built for the department of defense. And it was a huge problematic contract for EDS that they were around the time I was helping the senior analysts covering that, that particular company. That contract was up for renewal and it was a big question mark because essentially, like, I think, as I recall, EDS was losing a lot of money on that contract, right? Uh, the, the department of defense was able to lock in, right? So they were able to take this variability of this project that they had, which is basically build, build another internet, um, except one that only we get to use.

And they de-risked that by locking in this particular contract with a third party. Uh, but then as all derivatives do have, right, there's a, there's an expiration on that. And they'd only barely finished building it by the time the, uh, the contract was coming up for renewal. And the timeline, you know, for EDS to actually have to be profitable would have required them to have finished building it way earlier and then go into more of an operations maintenance mode. And that didn't happen. So now they were like, we need to get this renewal because we're only going to make money on this when we renew and are able to actually just operate this thing. Cause we just spent seven years or whatever building it. Um, so in that case, like that to me does, that's sort of sounds like what you're talking about. It's a little bit more extreme, I think, than just taking an individual code base. But, uh, there's definitely an analogy there of like, Hey, we're, we're going to take a big project that appears risky. And, but, but of unknown risk. And we're going to try and lock in some kind of interest rate around it. Um, but, and then someone else has to absorb that. So, but I guess where I was thinking of is, I feel like we, as an industry tend to get really hung up on like this fear of lock-in. And this concern about where we're getting locked in and who we're locking in when. And the people who take that to the utmost extreme decide that they're going to build everything themselves. And then like surprise lock-in party of one, you're locked into your own code base. Um, and all of the employees who built it. And I feel like one of the key parts of derivatives is it's that pooling of assets. And so the more that you rely, not just on your own code base, but on like shared tools or shared libraries.

And like things that can kind of help you, um, kind of collaborate, not just within your organization, but kind of across the world. And open source platforms, clouds, lots of options out there. But is that a way that we have decided that we can kind of pool our assets collectively as kind of a hedging thing? So that was, that was where I was thinking with that. Um, that does, of course, introduce other kinds of, you have the lock-in risk, you have the risk of, like a dependency risk that maybe you didn't have before. But I think that, um, I think it's interesting to think about how we think about risk in this industry and how we think about pooling that risk. Yeah. So I, I think what's interesting, there's another fun finance term that we get to introduce at this point in the conversation, which is liquidity. Right? So I feel like what you're describing is actually the liquidity of the market that you're in. Because if you're in, you know, lock-in party of one, which I love that expression, because you've built everything custom, and you've implicitly, if not explicitly, but you have implicitly accepted that you are willing to support all this code. Uh, you know, perhaps even the underlying open source projects, even if everyone else abandons the project. Um, and so actually, like, uh, uh, Josh McKenty had given me a great sort of overview spiel along these lines of that, you know, that trade-off between the sort of going with certain things that are either actual standards or de facto standards, and then carefully placing your bets around things that are the really emerging, uh, potential one-offs that you are having to say, you know what? If I'm the only person using it, that's okay.

I, it's, this is important enough to my business where I'm willing to take that. And then there's this really scary in-between zone where it's got a little bit of community, or maybe even a big community, but it's not a de facto standard yet. So you've got to make a call, and a lot of people essentially try to place bets there that they think it's going to become a de facto standard, but it may not. Um, and when it doesn't, and the community potentially evaporates, then what happens? Um, and so how does, where does that leave you in terms of liquidity? Uh, so, you know, you, in some ways, the most conservative position to take would be anything that's not a de facto standard. You should look at as, would I be okay if I were the only person in this community, and therefore we would be self-supporting. Is that okay? And if it's still important enough to your business, then, then do it. But you're, you're understanding the, the, um, you know, now you're trading fine art and not, uh, securities. I don't know if anyone else is going to enjoy this conversation, but I'm having a delightful time. Yeah, I was like, we might have some of them on a niche interest between you and I, but like, this is just like the best hour. Yeah, no, I'm like, I'm now picturing, like, you know, the Sotheby's auctioneer for that code that you wrote that is so one-off that no one else can support. Like, you're now, you've got an auctioneer up there. If you're lucky, it's a Sotheby's auctioneer. Um, but it's, it's probably not. Uh, so that's, uh, just, you know, cause they, I associate Sotheby's with like really high-end stuff where there is a market for it. We just don't know the price. Um, I don't know what the kind of like, otherwise you're maybe on eBay, just hoping that someone else is as deeply fascinated with your 1997 troll doll collection.

Um, I believe in the late nineties with Beanie Babies. Oh, I'm, I'm sorry. I'm, I'm way, I'm way off. I'm a little rusty on the, uh, the, uh, nineties collector phase things. Now they have all those dolls with the, like the really big eyes. I don't know. I've seen them at the toy stores. Okay. Yeah. They're kind of cute, but I mean, they get slobbered on. That's where they should be. They should stay there. Um, okay. Yeah. So entering because it's interesting, bringing the liquidity discussion back to derivatives, there's when you, the derivatives market, there's kind of two different markets. There's actual exchange traded derivatives where like those, um, the stock options and not, not the ones that, you know, tech companies give out to employees. These are like the actual, you know, exchange traded options. Those contracts are, they're standardized enough where, you know, they can just be electronically traded because it's just, it's, um, it's really well-defined and they're all basically the same. And so you don't have to worry about like this or that. Um, and there's futures markets for that too. And I always, my favorite, um, you know, underlying asset in the futures markets, like frozen pork bellies, like it's always amuses me that there's like frozen pork bellies. And why they're always frozen, um, I mean, I guess, because they're not really worth anything if they're not frozen. Um, but you know, so like the commodities markets use futures all the time, because if you're a farmer, you inherently stand to gain. It's weird. You actually stand to gain if, um, like the weather's bad and the overall crop is bad, but you somehow managed to have a good crop. It's a little bit wonky there. Um, but nonetheless, like if, if you have a good yield, you stand to gain because you have crop to sell.

So how do you hedge the risk of what if the weather is just really crappy where my farm is this year and I don't have as many soybeans to sell or whatever it is that I'm growing on my farm. So I'm going to write a futures contract, um, to lock in that someone else will buy at this price that I would like to be able to get anyways. But, uh, I may not be able to, and if I have a low yield, I need to get the highest price possible. Um, and same thing with like oil and all these commodities is like you, you already stand to gain if the price goes up. So how do you make sure that the, uh, you know, if the price goes down, you're, you're still taken care of, or at least you've offset some of those natural losses. Um, so those are really, those are big enough markets and they're defined enough where it's really standard that you have high liquidity, but then there's all these off exchange derivatives markets, which are sort of just negotiated between parties. And it's a huge market as well. Uh, and that's where you can't measure the liquidity the same way. And when suddenly you have no one to sell this thing to when you need to, then all of a sudden, like you're the one stuck with that interest payments. And that's a little bit of, you know, going back to the financial crisis is, you know, that sort of model. And what happens when you have low liquidity, uh, markets or hard to measure the liquidity markets. So to your point, if there are vendors standing by able to support the open source software that you're running, right. That that's an indicator that there's some liquidity in that part of your, your debt market that you're, you're trading on. Um, I mean, another extreme example is just, you know, going to SAS, right.

It's like, do you even need to be building this at all? Um, then like, I mean, if you can get away with not writing the code at all to the point of all the code is, is some form of debt, then great. Just let the business gain the asset without having to take on that debt. Great. So, you know, always be looking for those, like if you can do, if you can get away with it. And those are extremely high liquidity markets. So in theory, you should be able to like trade in and out of them. Of course, then you introduce all the integration software that goes with it. And that changes things a little bit, but, um, it's still probably higher liquidity than, uh, everything written custom. Yeah. So one of the things I was thinking of as you were talking is I feel like a lot of the examples that we've given is, um, maybe I hate to assign value, but maybe like a good or like natural uses of a derivative versus like a purely speculative. I would like to make money use of derivative and, um, which is probably because those other ones lend themselves more naturally to the metaphor. But I was just thinking how much fun it would be if you got to like specular, speculatively guessing their code base is going to implode. I want to bet against that company. Oh man. Cause I feel like that would be a, I feel like that would be a liquid market of a whole lot of shorts. Oh yeah. That I haven't thought about that. I'm not sure I even want to think about that. Um, yeah, I mean, and that starts to get into like an interesting, you know, natural question of like, well, if your code is in some ways, every line of code is debt, but your, your software is also an asset, right? Like what is the counter, uh, weight asset that you report? Like, why aren't these things reported on your balance sheet at all?

Cause that would then be something that you would have others in the market would have visibility into what those ratios look like, uh, and then be able to, you know, trade the derivatives accordingly. Um, but yeah, that would be, that would be terrifying to know like, wow, the short interest on our, uh, on our, our tech debt derivatives, uh, is not looking so good right now. Um, but yeah, I mean, what, uh, I feel like we're, this starts to kind of stretch the analogy, right. To like, to like, to some of the breaking points. I mean, I think it's great, it's great. You've got to find these breaking points, like, because sometimes it's only right up against the edge of the analogy that you find yet another lesson that you can take from it, uh, before the whole thing falls apart. Um, but you know, we're, it sounds like you're, you're kind of of the mind that we shouldn't throw out the analogy altogether. We just have to be mindful of, you know, yes, it is an analogy. So it is going to be imperfect. Um, and we can't lose sight of what the real challenge is around it. Yeah, I think exactly that. And then in addition is trying to remember what it is at the core that we're trying to communicate and then trying to make sure that that aligns with what our analogy is actually communicating. So just making sure that we've thought through, um, yeah, just thought through what we're trying to tell our business counterparts about the state of our, um, technical stack. Now, within that, I mean, if some of the things that have come to mind for me as how would you, like the, the goal isn't, um, to retire all the tech debt, right. That would mean retiring all of your code. Uh, it's great if you can, right. So that example I gave from discover where it was like 46,000 lines of code to 6,000. I mean, I can't remember what the exact numbers were, but they retired like 30 some thousand lines of code, right.

They, they just paid off that principle. Great. Um, and like in terms of, well, how do we, what should we be measuring to be able to talk to our business counterparts? That like, we're, this is code that we're in a good place on, like we've got a good interest rate versus this is code that like, if you want us to get that feature out, like, you know, here's all the, here's where the, the variable risk lies with that particular code base. Um, or should be, um, or should be, these conversations be happening outside of the context of new feature releases where it's just like more of a, a quarterly report or whatever, like whatever vehicle makes sense to just describe the health of the code. I mean, on the one hand, things like, I know having test coverage is important, but I also know that if all you're focused on is reporting that we have high test coverage, you can still potentially miss. The, the risks of being able to change the code itself, like not all tests are the right tests and the tests need to change over time. And so while test coverage is important and are the test screen is important, like that's, you, you risk kind of warping the conversation a little bit and falling into the trap. Yeah. And you just risk creating like poor incentives for people. Yeah. Just, just write the test for the sake of the test. So, um, one of the ones that I liked in your talk that you kind of talked about generally though is, um, like the friction required to make changes. And so like how frequently and how easily can you make changes? How brittle is your code base? So I think that there's probably a lot of things that kind of can feed into that as sub indicators, but I think that's probably the general metric that you're trying to convey. Yeah. And then like, I suppose that could just be, um, well, there's a great quote from Adrian Kokroff that I've used a lot where, uh, he talks about, you know, you want to go faster, like count up how many meetings and tickets it takes to get something done, publish the number and make it go down.

Um, and so, you know, yeah. How many, how many meetings and tickets, how long does that process take? Those are all friction points, right? Is every time you have to schedule a meeting for something, um, or submit a ticket, it's a, it's a point of friction. So I'm just, I have metrics on the brain too, as usual, because when do I not, um, so thinking about how do we tie thinking about our code as debt, there's then the, the question around trading derivatives and de-risking it. And who, who would, who would the buyers of that be? Um, but then also how do we at least just report internally on the debt that we're carrying? Right. And I think that we've expanded on a lot of possible ways to think about it, but I feel like we've reached the part of leaving the mystery with our listeners and letting everybody else mull this over. Yes. Um, let the mulling begin. Um, so any, any final parting thoughts for our listeners on that note? No, I think that, I think I'm coming back to your initial thing about people being discouraged by debt. Um, and I don't think that either as a person who is working on the code base or someone who's a counterpart to the code base, like the existence of debt is not an existential crisis. There's always going to be things that you need to work on. There's always going to be something in your backlog. Um, don't let that freak you out. Like that must be part of having code. So I think, I think it's kind of what you said, like none of this is inherently good or inherently bad. It just is. Yeah. And it's always tricky then. Like you're rehabilitating what had been perceived as a bad guy, but you're not, you're not trying to rehabilitate this character. Tech dead in this case, being the character, you're not trying to rehabilitate them all the way to being a good person or good character, good actor. Um, kind of like that, that awkward movie from a few years ago about, um, Maleficent, the sleeping beauty, you know, evil, evil queen, witch or whatever.

And then you're evil fairy. And then it's like, Oh, actually like she was this maternal character or something. It was like, but she still kind of did some like, not so cool thing. So, or the Vikings, you know, like everyone thinks the Vikings is like these sort of scary, scary folks in history. And then it's like, well, actually they built a lot of trade centers and provided the foundation of the economy in the later middle ages. I mean, I digress slightly. Oh, this is a good podcast. But in this case, it's like, we're not trying to, we're not trying to rehabilitate tech debt to being like, go out and embrace it and load on as much as you can. It's just more like, it's a tool. It's a tool. It's like, it's new. It's sort of neutral. You know, you don't need to demonize it. Uh, but you know, we don't need to make it a hero either. Exactly. Okay. Case closed. On to the next one. Yes. Well, pleasure as always. Um, and, uh, we, maybe we will discover who are the crossover finance technology geeks out there. Besides just the two of us, uh, who come out of the world. Maybe, maybe the third one of you can come on the podcast with us next time. You just make yourself known. Yes. Like raise your hand on Twitter. We'd love to find you that one other person out there who loves this stuff. All right. Until next time, this has been Pivotal Conversations.

Tanzu Talk · 🍕 Get more pizza.