Do We Want A World Without Technical Debt?

  |  Compiler Team  
Modernización de aplicaciones

Compiler • • Do We Want A World Without Technical Debt? | Compiler

Do We Want A World Without Technical Debt? | Compiler

About the episode

Software development teams often reach a crossroads. Should they perform maintenance and address bug issues, or add new features to satisfy users? The former isn’t as exciting, but sometimes the most important work is invisible to those who reap the benefits.

For now, the project has been released, and everyone wants to celebrate. But there’s an elephant in the room, one that teams can ignore—at least, for a while. We unpack the concept of technical debt, and wonder if there is a world where it doesn’t exist.

Compiler team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

Brent, hello. Hi. I have something to ask you. Okay. What do you think of when you hear the term technical debt? Okay. So one, I don't know what it is, but if I had to guess, it is technically debt? I don't know. Like, is it debt? It's kind of not the way we understand debt, but yes, it is a type of debt. Debt to me is like a financial term, right? So that's immediately where my mind goes, is like financial debt. But I'm trying to think through right now what that would mean in technical terms. What would technical debt be? Do you want me to define what this is in my own words, or... In your own words, yes. Let's hear what technical debt is. Sure. Technical debt is the cost of delaying necessary work on a project so that you can hit your milestones and you can release things on time. Angela, I think you might be familiar with technical debt, right? Familiar with it? I've created some of it. So yes, I'm pretty familiar with technical debt. It's the by-product. It's just one of those things that happens when you're moving things forward. Yeah, it just happens. So like not at all what I thought it was. It has nothing to do with your FICO score. No, not at all. No, okay. It is quite terrifying though. Right? The term technical debt, there's something about it that sounds very ominous. For sure. So today I wanted to dive into this term, because I didn't know what it meant either when I first encountered it. When I started digging and found out more about it, I wanted to know if there was the possibility of an industry being free of technical debt. Is that something that is even possible? And if we could do it, would it be a good thing? I wanted to find out. And if you're down, I can tell you what I've learned. I'm down. I'm down. Yeah. Let's figure it out. Let's do it. This is Compiler, an original podcast from Red Hat. We're your hosts. I'm Brent Simoneaux. And I'm Angela Andrews. We're here to break down questions from the tech industry. Big, small, and sometimes, strange. Each episode, we go out in search of answers from Red Hatters and people they're connected to. Today's question: Do we want a world without technical debt? Producer Kim Huang is here to help us out. All right, Kim, where do you want to start? Well, let me just start with a little bit of a thought exercise. Okay. So, let's imagine that the three of us are a development team. Like we're building software, right? Okay. Angela's in charge. Angela is in charge 100%. Ugh, okay. And we're getting around to... So this is after our initial release. So version 1.0 has gone out and now we're getting together to figure out what to do next. Brent, you might be concerned more about bugs and internal issues and optimizing the experience, making the things that are already there better. Mm-hmm (affirmative). But Angela might be concerned about new features and functionality. Things that customers want. Right. So because those two things don't necessarily go in tandem and there is an immense pressure to deliver new features, that part receives priority. Angela wins, and then the technical debt that was already there starts to increase. You want to ship it as fast as possible. Ship it. Get it out the door. But you do have to worry about the other stuff, too. Right. So I'm just going to say this: technical debt sounds bad. Like, it sounds like it could be really bad. I thought the same thing. So I wanted to speak to someone who had a good idea of how technical debt really works. I am Tramaine Darby and I am an engineering manager in the products and technologies division. So, the interesting thing that she says about technical debt is that it's not good or bad. It just exists. Yeah. Technical debt is generally talked about as something that needs to be cleaned up or a mess that someone has made or something that is just not quite right. I think that's just a slightly wrong way to think of it because it's not necessarily bad or it didn't come to be because of someone doing something wrong. It's really just something that is done because you're trying to move fast and you're trying to get things out and it's just not quite complete or the whole picture of what we need to deliver. I think of it a lot like if you're cutting trees, sometimes you have to slow down and sharpen your saw. So it's all those things that make it better to deliver in the long term. That is actually a really good analogy because you're actually doing the thing, but sometimes you do have to stop and assess and again, sharpen your tools, whatever those tools may be, because otherwise you really can't move forward without it. Yeah. And I will say what Tramaine was just saying about "It's neither good nor bad, it just is..." Mm-hmm (affirmative). That sits a little strange with me because I think that, like I was saying before, debt has a negative connotation to me. So I'm kind of fascinated by this idea that technical debt, it just is. I mean, the choice of word itself kind of makes you want to cringe a little bit, right? Because language matters. That word, it makes people feel a certain way. And especially if you don't know exactly what technical debt is, you're going to assume that it's something negative because that's what you liken it to. So fortunately, or unfortunately, it's one of those things that exist. Yeah. I mean, the way that I look at it is this: Yes, the word debt does add that negative connotation to what we're talking about without context, right? And also, debt is all about how you manage it, right? People often think that in order to be productive, that you always have to be cranking out new features, but I kind of go back to that cutting trees analogy, right? You'll be productive in the short term, but if you don't stop to sharpen that saw, your productivity is going to reduce over time. So it really is important to address that gorilla in the room on a regular basis, so you don't fall into the trap of having a dull saw, thus in the longterm reducing your capability to actually be productive. What usually gets left out, and this is just one scenario where you're working on a project and you're trying to plan forward. You're trying to cross your T's and dot your eyes, you're doing your testing, you're doing all of these things. And you're so concerned about moving this forward, this project forward, this sprint forward, what usually tends to fall behind is the small things that we don't really think about, like documentation, or how are we optimizing this? Or how are we securing this? You know, those are not little things, but they kind of tend to fall down because you're really trying to move something forward. And in Tramaine's analogy, when she's talking about, sometimes you have to stop and sharpen your tools, that's when you have to go back and say, "Okay, let's right this ship. Let's make sure that we bring our debt along." You know what I mean? To bring it into the forefront and address it. That's super interesting, Angela, because I think what I'm learning from you right now is that the choices that we make while we're building something, they're often small choices. It's a lot of really, really small things that add up over a lot of sprints or a lot of months or a lot of years. And if you're not really paying attention to it, one day you might look up and think, "Oh my God, we have all this debt." You know? We, this big pile of debt now, where did this come from? Exactly. How do we address it? The other thing I wanted to talk about, because Angela, you mentioned documentation, right? Yeah. So Tramaine talked about how documentation can sometimes be a very unanticipated, and sometimes, well, in her opinion, the ultimate in technical debt. As soon as you produce a document, it's almost out of date as soon as you put it out, right? So anytime a bug's fixed or an enhancement or just any general change to software is not reflected in that documentation, it just diverges from what the as-built software is. But you can't really get around that. You just have to kind of stay in front of it. So again, as the end user, who may need to rely on this documentation, what are you doing? Because it hasn't come along. It hasn't met you where you are. So you're not getting the value out of it because that debt exists. And it's now starting to impact you as well. So talking to Tramaine, Kim, what kind of struck you about that conversation? I was completely surprised. I didn't imagine that something called technical debt could just be a by-product. I thought it was something that would be a little bit more, I don't know... nefarious. Yeah. I came into this conversation with a lot of negative connotations of debt. Like, "Oh, we have this debt, whose fault is this?" You know, like who do I point my finger at? I think that is a really interesting point. I mean, it is a part of doing business. So you don't have to assign it any feeling one way or the other, because it's not going anywhere. It's just there. I feel like this is such a, I don't know what the word is, like a... Academic? Academic, maybe. No, I mean, I was going to say it's such a peaceful way of looking at the world. Like it's neither good nor bad. It just is. Like it just exists. We don't have to assign a judgment to it or a label. If all things could be that way, right? Yeah, right? I spoke to another person who had a little bit more of a positive outlook on technical debt. Hi, I'm Sherard Griffin and I am the director of AI services at Red Hat. So I was really happy that he chose to talk to me. He was really interested in the subject of technical debt. I actually love this topic because a lot of times, when you are kind of on the bleeding edge of things, you know that you're not going to have all the answers for how technology needs to fit together. And in this case, what we do with AI in ML, in machine learning, it's such a rapidly changing environment. It's inevitable that a huge chunk of our code base will have technical debt. He says that technical debt first shows up, and he was talking about from like an internal perspective, when people are getting together in a room and saying... "You know, we can, we can shoehorn this in." And it's kind of, we're taping things together here, but we should really rethink that. It's here that really, the chief driver in the software development process comes up again and again, and that's time. Yeah. There's never enough time... Never enough time. ...to fit in all of the work that needs to be done. So the technical debt, it kind of has to exist because there's timelines and there's deadlines to meet and trying to get things out to market. Yeah. Like imagine what your timeline would look like if you had to address all of the innovation and all of the moving forward, and then you had to bring those other things along with you. Nothing would ever get done. One of the things that we always have to measure is, how much is the technical debt impacting our ability to hit that timeline? Getting code out the door? Do we want to make our deadline or clean up our code? Yeah. I think what I'm hearing from Sherard and from you, Kim, is this fundamental tension between innovation and maintenance. Yeah. Is that right? Yeah. And the added dimension to that is competition. If customers aren't getting what they need with you, they're going to go to someone else that's going to give it to them. Yeah. And this image that Sherard brings us of people in a room, having a discussion about how to spend their time... I've been in these rooms before and I think we all know what this feels like. There can be pressure from the rest of the business. There could be pressure to innovate, right? The allure of the new feature, the allure of producing something shiny is strong, right? There is a will toward newness. And it's really hard to focus on the maintenance, you know? Because that stuff is not as exciting. And customers can't really see it. Yeah. So, Angela, what do you think? Does this correlate with any of your experience? This is true. You only have a finite amount of time to get things done. So you have to prioritize those things and you do have to be mindful that there are other folks that are chomping at the bit just like you. Your competition is out there trying to take your spot. So you really do have to find that balance, making sure that you're being in the forefront. But what about the stuff that really matters just as much but isn't as pretty or shiny? You can't forget about it. Yeah. So what I'm thinking about right now is this concept of time and decision-making. Like, as you're making a decision about, and I'm going to be really over-simplistic about this, but innovation and maintenance, it's not a binary choice, right? It's not, "We're going to do 100% innovation and 0% maintenance." There's a decision to make there of like how much time are we spending on something new and how much time are we spending sharpening our tools. That's a really good way of putting it. And I certainly hope that it's not 100%, one or the other. I don't think that zero-sum development would work out very well in either direction. But you know, those are hard decisions to make. I mean, I would guess. Is that right? Angela, does that ring true to you? Yeah, so it really is a fact of life. Someone has to make the decision of what's important, how fast we're moving, what we're going to do, but you can't forget about the other stuff. So there has to be someone striking this balance and making sure that innovation happens, but you're handling the other stuff, as well. I want to return us to today's question. Do we want a world without technical debt? What do you think, Kim? I don't think so. If there was no technical debt, then things would just stay in development for a long time and deadlines would be missed, things wouldn't launch and customers would go without their needs being met. I guess the next question is like, is it possible to have a world without technical debt? I think what we're learning is no, right? You know what, the more I think about it, the more I think that that world can't exist. I mean, think of the times that we're living in. We're living in a world where products and services are shipping so much faster and that innovation has a cost. So we're bound to have technical debt, no matter what, it's just here to stay. Remember the days when it would take a year, 18 months for a project to come out and you would only ship maybe once a year or every 18 months? Well think about the other 364 days, you were literally spending the rest of the year trying to fix and maintain and address bugs and tune and optimize. And then somewhere along the line, you'd have to do it all over again. I don't think that world exists. It sounds like from what you were just saying, Angela, that we might even be looking at a world with more technical debt? And if there's no getting rid of it, I'm really wondering like, how do we handle it? How do we manage technical debt? That's a good question. And I do not feel qualified to answer it. There's a lot of different approaches and opinions about technical debt out there. What I really want is to hear from the people that listen to this show. I think that's a really good idea, Kim. If you have dealt with technical debt, if you have experience with technical debt, we want to hear from you. Yeah. We really want this show to be a conversation. And so I would love to come back to this topic on a future episode and let you know what we have learned from all of you. So, okay, listeners, how do you handle technical debt? We want you guys to hit us up on Twitter and Instagram at Red Hat using the hashtag, "compiler podcast." You can also hit me up on Twitter at "Scooter Phoenix." I would love to have a discussion about this with you. That does it for this episode of Compiler. Today's episode was produced by Kim Huang and Caroline Creaghead. Victoria Lawton makes sure that we slow down and sharpen our saws when needed. Our audio engineer is Kristie Chan. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Big, big thank you to our guests, Tramaine Darby and Sherard Griffin. Our audio team includes Leigh Day, Laura Barnes, Claire Allison, Nick Burns, Aaron Williamson, Karen King, Boo Boo Howse, Rachel Ertel, Mike Compton, Ocean Matthews, and Laura Walters. If you like our show, please follow us for future episodes. We would love to see you here again. All right, goodbye, everybody. We'll see you next time.

More about application modernization

Involves the improvement of performance by updating legacy systems to newer technology.

Publicaciones en el blog

Friday Five — August 15, 2025 | Red Hat

15 de agosto de 2025  |  Red Hat Corporate Communications

...

Publicaciones en el blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 de agosto de 2025  |  Brian Stevens

...

AI inference

Programas originales

Steve Wozniak | Command Line Heroes

Historia de la tecnología

Programas originales

Command Line Heroes: Cuarta temporada: Hardware open source: la alianza de los fabricantes

Open source
Historia de la tecnología

Sobre el podcast

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.