Tech Debt CANNOT Wait For Tomorrow!

so there's this seemingly endless battle between addressing Tech debt and refactoring code versus delivering features and Bug fixes to customers and if you're someone who's working in a software company and not just you know making projects on your own and that kind of thing you'll have experiences for sure right so it doesn't matter if you have dedicated product managers or anything like that if you're in a position where you are shipping code to customers this is something that has to come up and I think that there's like in everything in life basically when you take extremes to things that's generally not the best answer so if you're always addressing Tech debt or never addressing Tech debt both of those situations are not great so I wanted to talk today about refactoring code Tech debt when to address it how to prioritize it when to prioritize it versus delivering features to customers so I wanted to make this video because I saw a post on LinkedIn that just did not sit well with me and this is a topic that I really am passionate about and I think that I'm in a position to speak about this because I spent almost 10 years at a startup that had to really focus on shipping value to customers and we absolutely had Tech debt we absolutely had periods where we had to refactor code or we were looking at things going wow this is Legacy how do we address it and I wanted to kind of chat through at least my perspective on how and why to address Tech debt and stack that up against features for customers so the way that I wanted to frame this is kind of looking at two opposite ends of the spectrum that I kind of mentioned right so if we take and I'm going to generalize a little bit here so I apologize because generalizations aren't great but if you take the you know the extreme programmer side that is focused on sort of like an academic perfect code perfect architecture situation if you left programmers like this to their own accord they will absolutely spend all of their time refactoring code trying to get a perfect architecture and they will you know spend tons and tons of time doing this and that's not to say that they're not delivering value to the code base it's not to say that they're not making the code better more organized so I'm not trying to say there's no value in that however if you think about like the 80 20 rule there's generally a point where it's like you're not neces you're getting diminishing returns let's put it that way so on one end of the spectrum that I'm talking about you have all of your time being put into refactoring code addressing Tech debt getting a perfect system in place but the reality is there's never going to be perfect code and the longer you spend doing that yes you might be putting yourself in a situation where the next set of features and deliverables you have they might come easier and faster as a result of what you're doing you might be making the code more testable all these great things and kind of setting yourself yourself up for faster delivery but while you're doing that you're not actually delivering value to the customers and it's kind of like a hard pill to swallow right because as programmers we want good code we know that there's value in having you know testable extensible code but your customers don't actually see it that way your customers don't care your customers don't care what your code base looks like they don't care what the test coverage is they care about the results of those things and they care about having the features and the stability from their perspective right they don't need to know or care or have any insight into if your build system fails a hundred times a day and produces one magical build that you can ship they don't care they don't know that right they only know what they're using and what they're seeing and interacting with so in that example obviously that would suck for a development team right no one no one wants that situation but your customers don't know that right so that's one like one kind of uh exaggerated example where you know a development team would be like we have to invest time into fixing this and I would agree that's a pretty crappy situation but the point I'm trying to make is that your customers don't necessarily see that and you can say the same thing about you know the architecture of your code how your code is organized your customers don't care your customers care about getting the value delivered to them so there's a balance to be struck and I want to kind of jump to the opposite end of the Spectrum which is I'm going to again make a generalization here but people that are very focused on on the customers customer proxies so it might be your product owner your product manager depending on your organization how things are set up this could still act like just definitely be software Engineers that are are the people in your group really focused on that so I'm not trying to pick on particular roles I'm just trying to illustrate one into the Spectrum and on this end of the spectrum you have people saying like we don't care about tech debt right and they always um position things as we got to ship this the customer needs this the customer needs this bug fix the customers are really asking for this feature um it might be the sales team promise that the customer could have this yesterday or something and you have this urgency around shipping things and obviously this is the exact opposite end of the spectrum so as you're trying to prioritize that kind of stuff and not Tech that this is where I think a lot of people think about tech debt in general right because it's like this deliberate Tech debt as programmers you're in the situation where you're like okay like if we really need to ship this feature or this bug fix like we really wanted to clean this up the code's not in great shape to do it but like if we really need to we could take a shortcut we could skip the tests we could go hack this thing in and the customer can get their feature so there's your deliberate Tech that example and again so we have two opposite ends of the spectrum I just described and like I said at the beginning of this video I think in basically all things in life when you take things to an extreme um you're you haven't really actually optimized for like a good solution so in my opinion there's a good solution somewhere in the middle of this because both of the things that I just described do have value and it comes down to priorities so I had talked about this previously I've made a couple posts on social media about this and my stance on this is that you need to be prioritizing Tech debt and aligning it to the deliverables and trying to get a little bit ahead of the deliverables if that makes sense so in this LinkedIn post that I had seen that was saying you know you can't um you can't wait to do Tech debt tomorrow they had actually explicitly said that you should not try to align Tech debt like fixing Tech debt with features and their argument was that it's going to slow down the delivery of features to your customers so the idea there is if you've set up time to you know go deliver a feature or something to a customer and then you're scheduling Tech that is part of that they're saying well that's going to take longer to ship that feature and yeah I mean that that statement's not incorrect but I think when we're talking about priorities I'll give you a counter example that I think will help illustrate my point and it's gonna it might sound exaggerated but I can think about code bases like this so let's picture a code base it's pretty big say you've come into a company or you've been part of this company and the code base is you know somewhere between five and ten years old something like that so it's pretty mature and let's say there's parts of the application or the service or the code base is big enough where there's multiple applications multiple Services what have you Let's Pretend There's part of this code base that is functioning hasn't really been touched in let's say five years right it's functioning but if you were to look at the code you'd be like holy crap like like I don't know who wrote that maybe it was you I've certainly been in situations where I've written some nasty code and five years later been like oh man I used to think this was good and uh oh but when you're looking at code like that you need to be asking yourself like is it functioning right now is it causing us problems do we plan on touching this code have we been fixing bugs in this code and it's brittle and if you build on that last point and is it not testable and I've talked about this in other videos too everything's testable but do we have difficulty testing it because it's a lot of investment to do so if you're asking yourself these questions and the answers are kind of like well the code is working no we haven't been having problems here no we don't plan on touching it to add new features no we haven't had to go add more test support and things like that all of a sudden you're getting into this the situation where the priority around addressing Tech out there is getting lower and lower on the scale of actual priorities right so if I were managing teams of software engineers and I do and I have been doing this for about 12 years now if I had an engineer come to me and say we need to go address Tech debt and I said okay let me hear about like the reasons why and let's talk through it if they Define or if they described an area of code like I just explained to you and started telling me out the code's not actually changing no it hasn't been a problem but really their argument is just like it's pretty nasty code and I want to fix it up I would probably say no if we have other priorities and if you have pay-in customers odds are you have other priorities it's probably not a good time or a good use of time to invest in fixing that Tech Deck and again that's probably a hard pill to swallow because I just told you that code was gross and nasty people want to go fix it it's just not the right priority now if this person said I would like to go fix this as a passion project I think I can clean this up and make it better okay um you know I don't necessarily want people to go work extra hours and stuff like that but if someone was genuinely interested in trying to do that that might be something we could explore there's risks associated with that there's risks there's trade-offs with everything right so even with a passion project to go fix up some Legacy code and make it better I would probably want to support that but I would need to caution them that okay based on you know different circumstances or variables if it's not well tested like you are risking regression so there's a trade-off but this would be something that I might want to explore if someone was saying look on top of my other priorities I would like to accommodate this but my point here is that in terms of you know a stacked rank priority list that kind of tech that would not be worth it so what tech that is and going back to this this LinkedIn post that was saying not to schedule it with features again their point their point is fair if you have deliverables that you're trying to ship and you're scheduling Tech debt alongside that yeah it's going to slow you down I get it but I think that is the right priority for Tech debt and it's not quite that black and white so if you ask a similar set of questions right so if we go back to okay maybe this code is also five years old right okay have we touched it recently you might say no we haven't been touching it recently but we plan to to deliver these features okay and the code is really nasty okay like code being ugly is not really a good argument it's really about what implications that has so okay it's hard to test okay that's a pretty good argument and we don't have any tests right now also a pretty good argument and us working in there um the code seems really brittle so um even the first thing we kind of try to prototype in there we were introducing bugs okay Another good argument right you start to try and Define why this Tech debt is worth addressing just saying the code is ugly and you don't like it and you want to make the code better and more perfect it's just not a good argument it's not a good argument for prioritizing against other things so in the situation like this what I would ideally like to do to try and address this person's concern about slowing down the deliverables is having a good relationship between the people that are on one end of the spectrum and the other end ideally over time people start to merge towards the center and I feel like when you have a really cohesive team that understands like you know you have some people that are like really focused on the tech debt and having really clean code and really well organized versus the people that are always trying to ship things as fast as possible over time when your team becomes more cohesive working together for a while understanding each other really well I feel like these parts move together and I've absolutely had situations where the relationship it doesn't have to be between a software engineer and like a product manager but in my circumstances it was where we have from the product management side more of this like ship it fast perspective and more from the engineering side hey we want to make it perfect kind of thing and over time we get a little bit closer but what's really important is those conversations between the two groups are happening people are going through the exercises of explaining why that Tech that's important you're aligning on the values behind addressing that Tech debt aligning on the values for shipping the features to the customers because when you're not aligned on those things you have this this is why you have two opposite ends of the spectrum people are valuing these things differently and I think fundamentally it comes down to when your team is cohesive you can have aligned values and it makes these conversations easier a lot of the time when you're in that situation where you are a more cohesive team when people are debating like ship it fast versus address the tech debt when you have those conversations generally what's happening is that people were missing some information on the other side so for example if you had a product manager with a product manager that was like we really want to ship this faster customers asking for it and it's pretty it's pretty urgent to the customer you might have someone up from the engineering side say look like I get it makes sense like we think we can take a couple shortcuts here but something I'm really concerned about for this code is we just need an extra day I'm just making up you know a time frame here but we need an extra day to make sure that we can get the right tests in place because right now it's pretty brittle and there are no tests and just to make sure we have that confidence we really want to spend that extra day a conversation like that is super powerful because from the product management side again if you're more cohesive and kind of gelling together that product manager might say oh like I didn't actually realize it was that brittle and you're not telling me Oh it can't be done we need months to do it but you're you're compromising and coming up with a middle ground and like again I'm gonna say it but like it might be a hard pill to swallow for some people and that's because you might be on one end of the of the spectrum that I'm defining so I think that ultimately you want to try and get closer to the middle where you are prioritizing Tech debt because it is important you do want to be refactoring code to clean things up it will help you move faster make things more testable be more reliable it's important shipping value to customers is important right that's that's what you're going to be getting paid to do that's how you keep the business running it's your customers and of course if you're not addressing Tech debt you get to this point where the rate at which your shipping value to customers is shrinking and shrinking and shrinking and obviously you run into some problems so they are both important to address but I think the conversation around prioritizing these things needs to be happening regularly and you want to try in my opinion you want to try scheduling Tech debt just before trying to get into a position where you're delivering features I do think if you're going off on tangents to go say this Legacy area the code base that no one's looked at in a decade and it's been working but it's ugly if you're doing that it's just not a good use of time um ultimately and again I want to my my framing here is I did work in a startup for just under 10 years and it was an extremely successful startup not my own but extremely successful and we constantly had to have conversations like this and they were difficult conversations I can guarantee you if I could interview anyone I worked with and I was like do you remember talking about this feature or shipping this version of the product I guarantee you people would say yeah those were hard conversations but they were good and they were good because they were difficult conversations but at the end of them we had to compromise and align with each other and I do think that those conversations at the end of the day make teams so much better and the more time you spend together doing that you'll uh you'll be fascinated like how much more performant the team becomes so I hope that wasn't too much of a rant I think that like I said both are important Tech debt and shipping features but I do think that you want to prioritize it your Tech debt alongside ideally right before diving into delivering features so I hope that helps that's my perspective on it if you disagree I would love to hear from you you can put it in the comments we can have a chat about it um but that's my stance so thanks for watching I hope you found that insightful and we'll see you next time