Command Line Heroes - From Compiler: Do We Want A World Without Technical Debt?

Episode Date: October 26, 2021

Who says tech talk has to be boring? On Compiler, we dig into tech topics big, small, and strange. We talk to people who know the code, and bring their perspectives back to you. Intrigued? Here's a preview 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. In this episode of Compiler, we unpack the concept of technical debt, and wonder if there is a world where it doesn’t exist.

Hey, Saran here. We're halfway through this season about the robot revolution, and I hope you're loving it. I wanted to share something else I thought you might love, and that is a new show from Red Hat called Compiler. This new podcast breaks down questions from the tech industry in a fun and approachable way. It's just like you're sitting at a table with some curious people. And those curious people are hosts Angela Andrews and Brett Semino. They have different backgrounds in tech, as do their producers, but together they're asking some tough questions. And to find the answers, they hear from a range of experts that work in our industry. It's fun, informative, maybe fuel for

your own conversations with colleagues and peers. I listened to one episode about superstitions, and it made me wonder, what are some other superstitions developers have? I don't think I have any, but I loved hearing the ones in this episode, and I'm sure there are so many more. But the one about technical debt really made me pause. I've always thought technical debt was a really bad thing that we're always trying to get rid of. But is it all that bad? Do we want a world without technical debt? Interesting question, right? Here's Team Compiler wondering if we'll ever be able to do without technical debt. Enjoy. 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, like what that would mean in like technical terms.

Like 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, right? Familiar with it. I've created some of it. So yes, I'm pretty familiar with technical debt.

It's the byproduct. 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. It is quite terrifying though, right? The term technical debt is 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 Cimino. 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%. Oh, 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. 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's 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 Tremaine 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 kind of 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 Tremaine was just saying about it's neither good nor bad. It just is. 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, 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 kind of negative connotation to what we're talking about without context. Right. And also, that is all about how you manage it. Right. 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, you know, 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 long term 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 for it, you're trying to cross your T's and dot your I's, you're doing your testing, you're doing all of these things, and you're trying to cross your T's and dot your I's, 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 optimizing this or how are we securing this? Those are not little

things, but they kind of tend to fall down because you're really trying to move something forward. And in Tremaine'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 write this shit. 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 kind of learning from you right now is that the choices that we make while we're building something, they're often small choices. It's like 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. Like we have 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 Tremaine 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 bugs fix or an enhancement or, you know, 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 like talking to Treme and 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 byproduct. I thought it was something that would be a little bit more, I don't know, nefarious. Yeah, I think, you know, 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. 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, you know, 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 just 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 and ML and 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 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 kind of 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 in 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, hit 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 was 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,

you know, 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, you know, really oversimplistic 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 percent 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, OK, 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. And that does it for this episode of Compiler. Today's episode was produced by Kim Wong and Caroline Craighead. Victoria Lawton, make sure that we slow down and sharpen our saws when needed. Our audio engineer is Christy Chan. Special thanks to Sean Cole. Our theme song was composed by Mary Anchetta. Big, big thank you to our guests, Tremaine Darby and Sherard Griffin. Our audio team includes Lee Day, Laura Barnes, Claire Allison, Nick Burns, Aaron Williamson, Karen King,

Boo Boo House, 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.