Technical Debt

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season when we're talking about patterns and any patterns of software architecture. This episode, we're going to talk about something that you've heard about, but may not have considered a pattern or any pattern. In effect, it is a little bit of both. We're going to call this one technical debt. Now technical debt is often thrown around in agile type approaches in particular. And basically what happens is that we are embracing that Pareto principle, the 80-20 We're going in, we're building out a lot of functionality and pieces and usefulness to our user. However, there is sort of a backlog of finishing touches. It builds up over time. We get something that is 80% there and we say, all right, we'll throw that out there. We'll get it reviewed. We'll let the user give us some feedback. And at some point we will come back and we will finish it off. You know, maybe put that in quotes. We will add some of the finishing touches, clean it up and things like that. And what happens is it's not uncommon, particularly if the finishing touches are not visible or highly noticeable to the user. That those things just languish. But which would be the anti-pattern part of it. But in general, those things that we say, we're going to do this later. It's something that we can, we'll say, get away with for now. And it's a, maybe it's a solution that is good, but could be improved on. Those kinds of things go into the pile of technical debt. Now as a pattern, this in particular in architecture is also an approach really, it's probably not going to be called that, but it's also sort of approach that is fairly commonly used and very useful as far as patterns go in architecture. And that is also referred to maybe as a phased approach. If you think of an architecture document or maybe something similar to architecture where it's more like a roadmap and you see dotted lines, you know, particularly, you know, maybe there's some boxes or shapes that have dotted borders or maybe even see an entire section of the map or the architecture that are, you know, dotted lines or colored differently or something like that to signify this is going to be something we're going to tackle in the future. It's something we want to do as we're building out the architecture. We want to be aware of it because we want to build the proper hooks in to be able to tackle that at some point down the road. But also we don't want to do it right now. We maybe don't have the time or it may be something where we have certain features we can provide to the user sooner rather than later if we cut a couple of corners. And it's in this case, it's not really cutting corners because instead it's saying we're going to we're going to rearrange things so that we can essentially complete certain items sooner rather than later. And in an architecture, the key here is the planning for that future, those future enhancements. It is putting things in place when you're architecting it to say, hey, we're not using this right now, but we're going to use it in the future. And so we're going to stub it out or something like that. If you think of a house or a building architecture, it could be situations where, let's say, water or air ducts or some sort of pipes or things like that, maybe even electrical is run through the building, but maybe capped off somewhere or not. Completed, you could think about it if you have maybe you have cable or something like that where cable is running down the street. Maybe it's on telephone poles down your street. And then it's not until they actually want to connect to somebody that they will then run a wire down and into your house or something like that. So the pattern here is it's not just planning for the future, but it's actually a specific plan for the future. So in this case, we are tackling actually some of the work of that future feature of building that into our system, but we're drawing a solid line basically somewhere. Maybe it's just a line in the sand, but we're saying we are. Only going to complete this to this point, and then we can come back later and we can pick this up. And there are many ways that this can be utilized to give us a really solid foundation in first version of our application that then can be quickly enhanced down the road. Another great example would be if you've got some sort of an integration feature that you're going to be dealing with. And maybe in your first pass and your first version, you have an import and an export that are very tightly defined. And maybe even you have something that runs that export on a daily or hourly basis, but then there's nothing else on the other end. So maybe it's looking for files to import and there's nothing placing files import or there's, you know, it's dropping files somewhere to be exported and there's nothing that's actually picking them up. Sometimes, you know, that would be actually pretty far into your implementation, but it would allow then for an integration to be very, very quickly spun up and down the road. Now within architecture itself, usually this technical debt is not going to be an integration per se, because that's tech. You know, you could say that that is, I hate to use the word tech, but that could be considered another application or pushing that off to somebody else. More specifically, technical debt tends to be internal. So instead of an integration, it's going to be more a, like thinking of that architectural picture, we have some features or some internal integrations or data passing that we're going to need to deal with. And we want to make sure that we take those into account and properly stub off or mark, you know, under construction, certain areas so that we can build out the features we want to focus on. And then we can come back later after, you know, maybe after release and say, okay, now we've got some feedback. We've got what we, what we really needed, including maybe some time or resources to build out these additional pieces. So technical debt is while sometimes a, like I said, almost an anti-pattern is a way to just kick something down the road. That's really where it's just being misused because what you really want to do with it, you want to, in order to make this a pattern is to be very intentional about when you do and do not push something into that technical debt column, this again goes back to that whole 80 20 approach, what do we need? And maybe even a minimum viable product in a component sense, what do we need for this thing to be functional to get us across the finish line in a sense, but we know that there's more that we want to do. And it's example of a performance is always a great example. Hey, we can make this work. This report will run. It just takes five minutes to run. And we know we can speed it up and get it to, you know, sub second or five seconds instead of five minutes. However, that's going to take extra work that we don't want to tackle right now for a broad range of reasons. You never, you know, there's all kinds of reasons that are valid reasons to push something off until later. It may even be that there are pieces, there are other requirements that have to be fulfilled before you can even do that. For example, if you are, let's say you're importing data from some other system. Well, if that system is not spitting that data out properly yet, or hasn't fully defined what the output looks like, you really can't advance your source stuck waiting on that other piece, which gives us a variation on technical debt. That is not really at this point. This is where you get into, how do you define such things? You may not call it technical debt because instead it's really just something that's on hold. But it could be that instead of making a couple of pieces on hold, you take an entire section where those pieces are a part of it and you say, you know what, since we can't finish it, we're not even going to really start on it for now. This is something that we know we're going to come back to, but we're going to put it on a, you know, on a backlog or a backlog for a backlog. And there are different ways these things can be denoted depending on how you do your, whether it's scrums or whether you're doing waterfall or something like that, whether you have a, some sort of a backlog that you're working with, or maybe you just have a, you know, an issues list or something like that. As you may say, things that are, that are essentially falling into that technical debt that are, you know, maybe called some people call it like ice box or hold or freeze or, you know, technical debt or to be determined or something like that, there's a lot of different labels you can use, but they all come down to the idea of we can make, and this is where the pattern really kicks in, we can make forward progress on the solution as a whole and not be blocked by this, this thing or overly concerned by, or drag down a rabbit hole by this feature, this function, this section of the architecture by simply saying, we're going to effectively walk around it for now, and then we'll come back later. It's perfectly reasonable to do it. The key being you're going to come back later. It's like if you're cleaning your house and you say, oh, I'm going to, I'm going to skip this room right now because there's a bunch of people in there. And so it just doesn't make sense to clean that room. Awesome. But if you get to the end of it and you don't ever come back and clean that room, then you just skipped cleaning the room. Instead, you need to come back and say, all right, now I'm ready. It's, you know, whatever the situation is, is such that now I can finish it. I can clean it. People left the room, whatever it is. And I can check that off. And now I have a completely clean house instead of a partially clean house. And hopefully that image in itself is a great way to view the proper use of this as a pattern versus an anti-pattern. If you are passing stuff by and don't come back to it and don't revisit it, then you're basically in that anti-pattern kind of approach. If you are intentional about how you do it and you do come back and you do pick up those technical debt items, then you are leveraging it as a pattern. It's sort of like any other tool, you know, some, or figure physical tools, like a hammer, you can use it for constructive purposes, purposes, but you can also use it to, I don't know, beat down a wall or something like that. So there are positive and negative ways to use this tool, but I don't think we, we consider technical debt as much with the, we'll say the respect that it should be with the idea that this is something that is a pattern we can use that will help us get to a completion point actually sooner than we would otherwise, because we don't end up lost in something that we know is going to be either easier to deal with later or more well-defined or again, a broad range of reasons why you might want to pass that thing over for now and then come back to it later. I got to do it for this one. This is again, it's one of these new, and we'll call it new because I haven't seen it in the, or laying around somewhere as a defined as a pattern nor as an anti-pattern, but it also is sort of an interesting one for us to look at and it also is sort of an interesting one for us to discuss because it actually plays both sides and it may get you thinking that maybe there's some other patterns out there. There are ways that we see thing as a pattern or as an anti-pattern and it's because of how it's utilized, but if you flip it or use it in the proper way, it becomes an anti-pattern becomes a pattern. And that's not a bad thing to think about as you're starting to build up now. We've gone through, we've talked about a lot of patterns and anti-patterns and so it doesn't hurt to have that in the back of your mind when you say, I'm going to use pattern X, whatever that happens to be. Are you properly using it or are you just sort of saying you are doing it incorrectly and in effect, the worst of all worlds, you think you're using a pattern, but it's actually an anti-pattern. That being said, I'm going to wrap this one up. We will come back. We are not done yet, but as always go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts, we are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go, Develop-a-Nor podcasts and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great, if you go out to developernor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.