AA178 - Navigating Technical Debt: Balancing Speed, Quality & User Needs

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. I wanted to have a podcast about technical debt and I thought the best person to invite for the podcast technical debt was Alex. Welcome back, Alex. Thank you. I don't know why you thought I would be the best person to talk about it, but hey, I'm here. Why not? I needed, I needed someone who has done software engineering. And someone who has done all the prioritization that product management plays on TV and, and someone who can make hard calls. That's what I need. I needed someone who is an expert. And for this podcast, Alex, you are that expert. Oh, great. Stubborn and opinionated. All right. I like that. I like it too. That makes three of us probably, but can we start with defining what is technical debt for those of us in the audience that don't know what it is? We're going to use the ward Cunningham version as soon as the all this nonsense gets Off my screen. Basically when he was doing refactoring, trying to sell that to the management to do as part of the budgeting. So I'm going to use a product plan as a resource. I'm not connected to product plan in any way, shape, or form. But also they're not Jira. So there we go. So it says technical debt is a phrase originally coined by software developer, Ward Cunningham who is one of the Agile manifesto signatories. He first used a metaphor to explain to non technical stakeholders at YCash, Why resources needed to be budgeted for refactoring. Hang on, we're gonna put a pin in refactoring for a second. His quote years later Cunningham described how he initially came up with the technical debt metaphor. Quote, with borrowed money, you can do something sooner than you might otherwise. But until you pay back that money, you'll be paying interest. I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learn things about the software, you would repay. That loan by refactoring the program to reflect your experience as you acquired it. So he's saying we're gonna make some choices now, and incur a cost later. Basically he's using debt as an allegory for design decisions, I guess? It's not really about debt. It's more about interest. Technical debt is one of those things that is just basically a result of a decision. But while you made the decision not to tackle that debt, you are incurring the cost of interest, That may be in the form of bugs, that may be in the form of performance, that may be in the form of difficult to implement things on top, or in the form of support. So the interest is more important rather than the debt. Because if you don't have to invest into something, because it's good enough, I think that's a good deal. But the interest is what's killing you. So imagine like earning a certain type of income, but you're not actually repaying the principal, so you keep on incurring the interest. And while you're doing that, it just shrinks what you're able to do, because you're constantly getting Distracted by that interest. You just named a bunch of categories that are solid gold for anyone listening. The inability to grow the inability to respond. I support , , yeah, the inability to support what you have, like at scale, you know what I mean? Think about the velocity, right? So your team is operating at a certain type of velocity, but you know, a part of the velocity constantly needs to be dedicated towards managing performance of this one thing that could have been done better and perfect the first time around, except we made a decision that we were going to wait. So until we fix it correctly, we will incur that cost. And that's part of the pain that comes with a technical debt. You don't actually carry the debt itself. What you do carry is the interest to that debt. a lot of people when they hear the term technical debt, They immediately think, Oh, that's a bad thing, right? And I'm here to tell you that's not necessarily the case. Technical debt doesn't necessarily have to be a bad thing. The other thing people say is, Well, it must be it must be messy code. You ended up with messy code. Yeah, guess what? That's not technical debt. A mess is a mess. That doesn't necessarily mean it's technical debt. So just get the concept clear about what technical debt is. It's only, it's technical debt is only relevant when it comes back in some way, shape or form to hinder you. Messy code can still be working code, right? And that's fine. If you don't ever go back to it and it's out there and that's fine. Next, next release, you're going to refactor or do whatever. And it goes away. So it's not a mess. And I think this paper that or this article, I guess my product plan, they touch on that. You know, this reminds me of an experience long time ago when I was a tech lead, we had developers that updated certain type of libraries in a code. They felt like, Oh, there's something new out there. And they wouldn't tell anybody about it and just update. And as soon as they happened, the first thing that occurred is bugs all over the place. Unpredictable behavior, things crashing, failing without really knowing why. And one of the things that I always try to address is the fact that you kind of need a little bit of the isolation, and you don't want to upgrade. Just for the sake of upgrading. And this is kind of the point of the technical debt. Not everything that you delay doing is that sometimes it's a healthy decision to want to do that. A user doesn't really care what happens after they push the button. They don't really care if it's library 1. that's doing the thing, as long as it gets the job done. They don't care if the pigeon flies out and carries the message you know, in a analog format to somebody, as long as it does it reliably within a given amount of time. That's expected. So the nature of technical debt and trying to solve it, I think sometimes is misconstrued. You don't always need to address it and it's not always the debt. So the question is again, for me, it's always a question of the interest. What is it that we're suffering while we're not addressing it? Because if we're not suffering anything at all, why does it need to be perfect? Exactly. I agree with that. It's technical debt. It doesn't have to be always looked upon as being harmful. It can also be beneficial. It allows you to do things like get out to market quicker, for example, right? But the point is that technical debt is an intentional thing. It doesn't just happen because if it just happened, that's a mess, right? Having a mess is never rational. It's a mess. It's based on unprofessionalism, laziness, et cetera which basically means you have no chance of paying that mess back in the future. Technical debt, on the other hand, you can decide to either pay back, pay back some, pay back when, all of those decisions. So, what's the opposite of technical debt? The opposite. I can give you the answer if you'd like. Please. Over engineering. Yeah, for sure, Right? I was at an organization once that was an engineering led organization, as opposed to a visionary led versus sales led And the engineering led organization, they were always working on the next cool gadget, basically, whether there's a market for it, they had a strong vision. Build it and they will come attitude about their products, which I mean, now later in my career as product manager, I'm like, Ooh, yeah, if you're really, really in tune with your customers, build it and they will come great, but you really have to convince me like you have to show me that you're really that in tune with your customers because most organizations and engineering teams. They are not, they don't talk to the customers that often. Well, sometimes the technical debt is part of the features that are actually in front of the users, but there are other times it's something hidden away in the code, something that addresses the quote unquote illities, right? Supportability maintainability, scalability, all those other things that are invisible. So this is the time when you have to evaluate Does addressing technical debt help my users? And if the. Result is negligent. And if the result to the team, that interest is not that significant, you can carry that a lot longer. You don't need to tackle it at the right time. now with what you just said, in a normal product organization, we have product managers, right? We're not talking about a startup, Alex. Like we, congratulations, do we scaled? We're 500 people now most of our product people at the highest tiers are not product people. Look forward to another podcast on that topic. Most people that I think that would listen to this podcast that are not founders, I think their challenge with, with this category is I need to sell what you just said. I need to sell that to my management. If we're treating technical debt as interests, these are line items of interest that I do not care to pay down now, but these are items that if we pay down, we can vault ahead. Oh, how, how can I communicate through the organization of like, Yes, I don't care about these and I do care about these, but you just made that case right now. You care about those. So you're incurring interest. You're wasting time. You're wasting money. You're slow in progress. Well, those are all things that you care about. So if you want to address it, you actually have to put on that startup mentality and pitch. Here's why. These three things need to be addressed because we are too slow for these reasons. We're constantly doing this and we don't need to, and this is what's holding us back. So it's the same value proposition. We are wasting time and money by not addressing these things when they are small or reasonable in scope. Now here's the problem where people fall into the trap. They try to pitch refactoring or some Massive rework as a technical debt item, in which case you have to evaluate is it really a refactor or technical debt, or is it re-engineering or re-architecting. Yeah, because those are completely different scopes. So if you want to take bite-sized technical debt items, you should, and you should budget for it. You should plan for it. And if you care about your team, you should represent it. For example, one of the ways that we manage it on my team, I do not manage as somebody running the product. I do not manage the prioritization list of my tech debt items. My tech leads and engineering leaders do right. My architects do. So they actually advise me on the top things that they want addressed to help them along the way, not vice versa. So it's a completely different position. Most of the product managers technically, push down technical debt items. Meanwhile, I'm trying to build a collaborative structure where I'm getting advice on the technical things to build on. So it's really about representation and the representation is, again, by interest or the pain of the interest. I think it might pay us to just quickly delve into the different types of technical debt. Because it isn't just one and all, right? There's different types. So, the reason I mention that is because you might decide to sell Some types and not others, right? So the software engineering institute has a list of 13 different types of technical debt architecture that I'm reading their page now build that code that defect that design that documentation, that infrastructure, that people, that that's a good one. Process that requirement, that service. Service debt, serviceability, I guess text test automation debt, not being able to run test automation ' cause you're running too fast maybe. Or test debt in general. So those are the 13. You may not have to sell all of those. Some of those could be done in stride, so to speak. Mm-Hmm., we actually never qualify those. I'm listening to the 13 items. Yeah. For the first time in my 25 year career. Okay. So I think it's great that you bring it up. There are different types as, as obviously as you list it, but we're really only focused on maybe I'd say three or three or four. Yeah, I agree with that too. It's three or four big ones that people focus on mostly. So just to go back to the point you raised, Brian how do you sell that? You have to put it in terms of language they understand. Right? So technical debt as a phrase may not really jive with them. But the impact of technical debt in terms of real dollars. That usually is understood well by people, by stakeholders, what do we stand to lose, what do we stand to gain those sorts of things, in terms of dollars. There was something that you said, Alex, I can't remember exactly the way you phrased it. I'm thinking about product managers who are not like me, who do not have a technical background, who might not be able to say we're on this older version of something, and because we're on this older version, we cannot take advantage of these. Those kinds of limitations. So I can normally sell, Hey, because we're on these older versions, we can't do these things like, Oh, , that's not even a great example because that shows that I'm somehow in tune with the future roadmap of the technology. You're actually always in tune. It's just like me with my daughters, right? If you don't do this, you don't get X. Like you want chocolate, right? Make sure you eat dinner, right? After dinner, you can have your candy. and this is the same thing, right? After you take care of certain tech debt items, you can have additional value, but that's only one type, as Om said. In reality, there are different values that you will get out of resolving the technical debt. I think where most product managers fail is having a clear way to list technical debt separately, and prioritized in the order of importance, but not by the products that Division, but rather by the pains of the engineering teams, engineering teams need to own and represent the importance of the technical debt. However, the way we structure it, we structure teams in a way that product always reprioritizes things for features because solving a tech debt item is not sexy, but getting a feature out is accolade. So I think there's conflicting values here. Although the results for technical debt feature could be really strong. Here's an example. Take a tech debt item that is performance based that is actually being complained on by the users and resolve that one. And all of a sudden it's going to be brilliant and it's going to be picking up a lot of recognition, but solve something that allows developers to implement quicker. And you're barely going to hear a mention. Yeah, definitely. That's definitely the case. I know a lot of startups have this. Ship or sink kind of mentality, so just get it out the door, right? Rough or ready, doesn't matter. Get something out. Maybe it's a prototype, I don't know. if you're doing POCs, yeah, you're going to have technical debt. But that's by design, it's intentional. If you want to get feedback. But it's what you know, you're going to put that aside and say, Despite all of these things, give me feedback on the functionality. Right. Yeah. It doesn't matter if you have to click five times to get something done. We know we can fix that. Yeah. I think the world of product management, like the platitudes of the product management world will tell you dedicate a percentage of your, whatever your, your operational bandwidth, whatever it is, roadmap, velocity, whatever you want to call it. And they'll say dedicate that. To whatever your engineers or tech lead or whatever agree that is the top item. so there's always a percentage of your entire team's capacity dedicated towards resolving this category. Well, I like where you're going. I like that you're immediately pushing back on that because I feel the same way, like what you just expressed I feel the same way. It seems like I've kind of taken my hand off the wheel to be like, eh, whatever you guys say is going to happen. I'm like, That doesn't seem intentional enough if you can't make a decision, that means you do not understand the pain. Right? I like what Ohm said about certain things being intentional. As intentional, you're actually consciously making the decision. We're not doing this right now. We are doing this at a later time. And the question really is when is that time? Is that time now? How do you evaluate? Is that time now the appropriate time is the challenge. And if you don't have the full tech debt list in front of you, if you don't have the team that's able to freely contribute backlog items in the tech debt realm, constantly nonstop and organizing it and sorting it and prioritizing it on their own and telling you, Hey, we're You know, Brian, this is a number one item for us. If we do this, we're going to be twice as fast. Then you really don't have the basis of making the decision. And now you have, especially if you're not technical, you're going to say, you know what, I'm going to push it down the list. That's not important for me. Right. So to push that decision making up front and center, you need exactly that. You need the ability to see it. I mean, I've been at a company that celebrated the ability to get a lot of features out the door. They had a chart, it looked like aggressive and it went all the way up and said, Hey, we just released 370 something features and then I said, Oh, I've already seen that chart somewhere. Oh, the tech that chart has exactly same picture. Realistically, anything that you work on, unless you get it to perfection is always going to have some loose ends. And that's okay because the iterative nature of agile implementation implies that you will improve it over time. I always teach my teams, get it to work, prove that it works, then work on making it better. Whether that's faster, whether that's more reliable, whether that's to cover other scenarios, and then you iterate again. That's the nature of Agile. The opposite to that is the waterfall. You get to think up front and center about all the possible situations. You strategize. You design it once. Measure seven times, cut once, right? You implement and then that's it. I actually have an article that states that agile is the reason why tech debt exists because we're trying to iterate so quickly and we're switching gears to different feature priorities so fast. We don't actually get anything finished, not by engineering standards. We finish it by feature standards, by usability, but that's okay. This is where the perfectionist coder, software engineer with a perfectionist product guy, they take a look at it and go, hey, my user is happy. whatever the code does is good enough. And the perfect coder goes, but I can make it even better. Well, you don't need to, that's good enough, right? It works. Customer's happy. And this is the trade off that we're faced. So we're not wasting time over engineering to cover a billion scenarios. But we are already providing shortest path to value. And user value is what Agile is all about. Absolutely, very well said. Yeah, I couldn't agree more. What would you say to the ambitious CTO who says , welcome to your first day as a product manager, Alex. Thank you. Congratulations. Welcome to the company. We're so happy to have you. We need to have a feature roadmap for all the features you want to implement. But also we're going to keep a parallel roadmap for all of the technical debt that we want to try to pay down over time. And those are two different roadmaps. They are conflicting goals, right? You cannot have two priority one items, right? In the end of the day, you have to prioritize with index based prioritization. Something has to be more important. So both of these quote unquote backlogs need to be merged into one with a clear priority. Because when something cannot be done in the time allotted, you have to make a decision. Do you make it more scalable, supportable, maintainable, or do you deliver one more feature? And so it's good to have these lists separately just for the ability of seeing them side by side. But I think when it comes down to one team to implement, they have to be merged into one prioritized list. So you mean one, a one B or two different priorities? Are they the same? I get that all the time. People that's priority one. So is this, so which one's one a one B that's really one and two. I mean, the reality of what you just said, like that, that certainly hits home. I want to rant about it for the next 45 minutes, but I like, I wouldn't help anyone, that's like, I, I do that as part of my normal job. I'm scared about people that come into product management, like straight out of school. And I'm like, well, how do you know what, what the right balance of like technical enablers, you mean like technical specifically tech technology related work that you have to do along with feature work. How do you know when to pivot this is one of those, like the last podcast we did. Was along the lines of like it was intuition to get something started to know what the right thing to get started and then evidence to figure out how long to stay on it. You know what I mean? It was like, what is that balance? If you never worked in software development you know, I think we're trying to quantify things that don't really exist. Whatever you do is just what you do. It's kind of like we create our own destiny by the decisions that we make. Some people believe that there's some kind of a higher destiny for them, and other people think that, you know what? You get where you get to because you made certain decisions. So, I think if you take a look at that CTO that wants to handle it, And you can either interweave things and put it into the same priority list, or after you've reached your last goal, you simply allocate some time for stabilization and you say, you know what? Right now we're just going to tackle this backlog of tech debt items. The problem is that never happens. Usually it's easier to wait until you're doing some work in the same area to efficiencies. Let's say you implemented some features, it has tech debt items. But you know, there's going to be more features covering it. So it's a perfect time and, and again, being an architect, I take a look at something differently. Like people associate just like the definition of tech debt coming from refactoring people associate tech debt with refactoring. What does refactoring actually mean? It means that when you designed what you've designed and when you implement it, you simply had only a set of understanding of what you were building, or you basically just limited yourself on purpose to building something smaller. So being an architect, I always said this, you don't actually architect a solution. You refactor into a design. Because constantly as you're adding features, you're recognizing what you have to change. So refactoring is a healthy thing, as long as you keep on iterating on improving your product. But if you have to refactor just for the sake of refactor, that's waste. Yeah, definitely agree with that. I think a lot of times when, new product people coming in, Really don't have a technical background. how do they prioritize technical debt? Quite poorly, honestly, because one of the things that they always aware of is the pressure to deliver, right? And they don't think about making things better or making things right. They're always going to think about adding features. So they'll lean heavier on the feature side on their backlog. And as you pointed out, they'll put tech debt items further down in the backlog. And if that happens in perpetuity, that tech debt's never getting paid in accruing interest by the day. I don't talk about the things that scare me a lot on the podcast, but the things that scare me for the next generation of product managers especially, this is you know, you're incented on the number of features you put through, and I mean, you're incented on the next. thing that brings new users into your application or spikes the use of your application or whatever. Like none of these people are incented on all the ilities that you were pointing out before I mean, yeah, the one time your app crashes and you blue screen airlines all over the world. Well, hopefully that's not a junior product person running. I don't know, I've not dug into it. I don't know about that. So I can talk about my experience. When I started out I had this deep desire to please my bosses, right? So the managers and everybody else, and I kind of talked about it in the very first podcast that we did. I wanted to please them. I wanted to make them happy because, Hey, I'm building a career and I really had low confidence and gaining some recognition went a long way. if I wanted to please the team, I would pick up more of a tech that items, if I wanted to please the bosses, I would probably pick up features or I would probably pick up some other type of work. So in essence, it's just really understanding. How you make that decision is it really biased towards your Thought about pleasing people or is it really important for the product and kind of extrapolating your emotions out of it And I think that's a question we talked about this a lot product manager is Is not a junior role. You pop out of college get a QA job, get a coding job, get a business analyst job you know, take a look at these teams functions before you start to drive or have a strong mentor, right? If it's a big product team and you're just one of the people on the team, Then hopefully you're gaining enough mentorship where you can ask questions. Yeah. I don't want to keep beating the same dead horse, but I'm a big fan of the journeyman models of you're coming into the market. You know, work under the auspices of somebody who's got a few years on the post, so to speak. Not stop, right? And learn. But that doesn't seem to be a prevalent model these days. Sadly. We learn by mistakes, mostly. There's two categories I want to dig into. One was refactoring, which I think is really misunderstood, and we should spend a minute to talk about it. The other one was the concept of your product manager using technical debt for incurring technical debt. For a reason, like just like finance, if you're going to take on debt, like debt, like money debt for a reason knowing why you're choosing certain things and making that choice implicit, and then maybe, You should reflect that choice in your backlog so that, you're writing like a note to yourself in the future to say like you know, I owe you Brian in the future who made this choice to manage all my users manually and not build an admin system. while I scaled to 300, 000 users or something like that, not that I've done that ever in the past in mobile development of previous life. Who does that? Look I, I think if you look at the totality of what people are trying to deliver, you just can't deliver everything, right? Otherwise, you'll never get to market. So, yes, go ahead. Agree. Go ahead and put something out there. I agree with that. But with the intent. Going back to that word, put it in the backlog. To your point, put it in the backlog. We need to build an admin tool. What value do you give it? You wanna get ahead of the time when the customers complain about it, I see it now, many years later reflected as a product manager. The people that I'm punishing. For not building an administrative tool for quickly onboarding and scaling a lot of users, the people I'm punishing is the development team, because they have to deal like in this world of DevOps, where we don't have any administrators and the the developers are the only people that recover from our blue screens worldwide or whatever, like the development team's got to bail us out. So. I am choosing to say, look, this is what I'm using my development, quote, resources to do. And it's, I mean, it's a business decision that I have made and now we got to pay for it. But you're also punishing the customer too, right? I mean, the customer's having to wait longer before they can get onboarded. So there's direct or indirect value for the customer there. So technical debt has a lot of flavors as we talked about, but it also has a lot of reasons. Forget the decisions. There's a lot of reasons why technical debt exists. And. I'll give you an example right now. We've implemented a feature that basically pulls a lot of analytics and gives you some kind of results, but we call it analytics, but it's actually doing reporting is actually querying everything. And it's taken a long time to aggregate the data. There's a difference. Why? Reporting and analytics are different. One is real time and you don't query all of the data. You don't aggregate it. You basically have the real time information at that snapshot in time versus the ability to query a list and aggregate all the information, right? So the engineers, when they designed this, they designed. One system, they designed reporting, represented as analytics because they thought it would perform. It didn't. It only performed with their sample data that they decided to create at that point in time. Now, we have this debt. The report comes back because it represents analytics, runs close to a minute. What do we do now? So can the user be happy with a minute? Yes. The user can be okay with a minute, probably not happy. Not now this isn't early two thousands. However, we now have that debt. What does that mean? That means that we missed an opportunity earlier to have the better architecture, better discussion, and the number one explanation that we get, and most teams fall into it and agile is, well, we got it in the sprint. So we just started working on it with this sprint. the amount of teams that I've seen not break up the design time box as a spike before doing the implementation and committing, delivering the work within the same sprint as they're building the technical design. That got them into trouble delivering shorthanded solution is one of the reasons why the most severe tech debt problems exist. Now you get that feature, but your roadmap has a lot more important things to do. And you as a product now have to accept it in the form as it is, saying this is good enough for now. I don't really have the luxury for whatever contractual commitments that we have agreed to with a customer. I don't have the luxury of taking another iteration on this. So we have to keep moving with the idea that we will eventually come back. And this is self explanatory. Imposed tell tech that that didn't need to happen Om, help me out with this one. Cause I want to specifically tap your skillset, if we're just in time development and if we're slice of the cake in time, agile, right. It implies to me that were reserving enough time to truly do The architectural planning immediately before the work. In the story you just told me. What I'm clearly hearing as the product manager here is Brian, you're not giving us enough time to think about the entire solution and to architect and to talk to other teams, because in a scale solution, you'll have three, four other teams. Maybe you've got a dev ops team that does your deployment. So maybe that's a mix of agile teams and component teams and all kinds of other stuff. I'm hearing a business agility problem of we want to pivot fast, but we're pivoting so fast that we're leaving a bunch of stuff on the table. It's definitely a dichotomy, right? Depending on how quickly you're moving. So I think the evidence that I've come across in my experiences is that Kind of across a small spectrum, one is people don't do this proactive thing, right, of paving the architectural runway so they run across something, we can't do this now, it's gonna be next sprint or the sprint after, right, that's the lower end of the spectrum, the other end of the spectrum is Theoretically, organizations are actually do have an architectural runway that they're paving ahead of the mainstream development occurring. And if they've done this right, they land mostly in the right spot. They don't always land in the right spot because they're always surprises. And there are always last minute reprioritizations for which the technological framework, the skeleton doesn't allow you to go ahead and start coding in the next sprint. But that's very rare, right? So those are the two things that I've seen is across that continuum. People don't talk about this a lot, but it's very, very hard to have an architect in an agile environment. It's very, very hard because an architect is not part of the team. It architects sit outside of the teams. They share kind of the higher level vision, but the type of prep work that you're talking about a lot of times implies that the architect is going to do it, but it's not the architect that's going to do it in the right environment. It has to be a spike picked up by the team, presented in front of the architect for review, whatever that review may come as a recommendation, and then and only then does that become some kind of a work item in future sprints, is very difficult to achieve in a smooth way, especially once you have multiple teams going. And you know, there will always be times when teams are forced to pick up things that they think are small and they don't run it with a spike before they pick it up and this happens non stop you know, we always Overestimate the abilities of the team to resolve something and think that just because we story pointed it Right, and we have some kind of a number that we immediately understand it. Yeah, so the architect really should be working with the teams the whole time anyway, right, to your point but they provide the guidelines and then the team, to your point again conduct spikes. I'm a fan of conducting spikes for things that the team doesn't completely understand how to deliver. So yeah, n number of stories that they're considering for a sprint. Do you really understand team? How are you going to do every single one of those? Do you have everything you need? Right. And if you don't, that story needs to be broken up into a spike plus, right. And in the same sprint, if not the same sprint, put it back in the backlog, but at least conduct the spike now. Yeah. The podcast that will proceed immediately. This one we made a heavy Emphasis on team topologies, like the book, team topologies and one of the interactions methods of the way that teams work together is collaboration. Meaning like, like when we're planning work, when we're performing work, like my team is going to temporarily join your team while the work is happening that we need overlap for. And then I'll go back to do whatever. So if you're, if you're architect, for example, is a member of the, the team of leads, I'm going to put it in super air quotes for people that are listening. Where, where are my hands? Super air quotes that over here, tiny little super air quotes. Looks great. if they're, if they're joining your team temporarily to help you through the work and then bouncing off your team, because they got other things to do, you have this enabling team on paper that is all your people that are spread across the teams that are their leads, their managers, their enablers, basically to your team members. If that's where your architects sit, where they're not dedicated to any one team, but their skills are both required and needed on every team, right now, they're not required and needed 100 percent of every sprint for every team all the time, because that would be ridiculous. Everyone's experience is different, but only in my experience, like 90 percent of what you need is done during the planning to say, Hey, when you actually go to execute, Adding this trigger to the database or adding this store procedure or whatever, right? And when you actually go to execute it, get me on the call. We'll sit together. we'll peer and test it and make sure it works or whatever. Or we need to spin up this new environment or whatever, you can get them on the call and get them ready for that, That's one way, but team topologies also talk about vertical slicing where you do not wait for external resources that need to unblock you, right? hard uh, to implement agile with all of these facets on a multi team environment, it's very easy to run agile in one single team, working on feature development in the R and D team or whatever you want. It's very hard once you need to scale it and make it bigger. And then there's other people that are dependent. And that's the ultimate reason why people are like, Oh, agile is not. Great. Oh, I was going to say agile doesn't work here. Yes. That's a good one. It doesn't actually work here either. you're absolutely right. I'm like, if the borders of Agile are a customer finds value with what the development team is doing, and then you have to figure out how to constantly expand that border and then expand the next border and expand the next border. Yeah. It's going to get more and more difficult. I mean, the way to make it easier would be to figure out how to Take the larger organization and start breaking the larger organization down into boundaries So that certain customers only talk to segments of the organization, but at that point like now we're it we're in another podcast Yeah, design. I run two businesses and one of them is doing development for other businesses. So I have teams that are working for clients and I also have a startup. So one, which is working for itself. So where I have a team working for clients, we develop the software that's in the backlog and then we immediately put it through the demo and review by the client. And then the client comes back and says, Hey guys, we'd like you to take another look at here. We want you to iterate one more time here and it's finding improvements within the same implementation. So we don't actually get to a lot of technical debt because the client is helping us on iterating through, they're taking a look at it and providing the feedback immediately. On the startup side, this is where we have not a single client that can make decisions. We have. Lots of users and different users have different values. So we have to place bets and make our own decisions where we invest into the right stuff for the client scenario. They're investing immediately into a given functionality because they're looking at that final value for us. We're looking at the entire market, so we have to pick and choose. I think most people kind of don't really think about the differences in your teams. They kind of treat, hey, tech debt for us and tech debt for another team are the same. No, the context is different. That was such a good ending, but we didn't go back to refactoring. I want to go back to refactoring. Because as a, I feel the only reason I could dig into refactoring is because at one point in my career, I was a QA engineer and I understand about like, this test is not good enough. I need to go back the next time I'm in this test to fix it because I know what's wrong with it because I wrote it, but I can only imagine like, well, we're, we're, we're off of that feature, Alex. Like, I don't like, there's no reason to go back into it and change it. It's working in production. Don't, don't bother touching that if you're anywhere, anywhere near it in the future. Like I think I scared my team once as a product manager, my development team. I think I scared them once when I said, I don't want to talk about refactoring. Refactoring to me is something that just happens. And they were confused. They didn't know what I meant. So as a developer, if I come across code that can be improved and all I'm really doing is fixing one of the ilities, but I'm using refactor tools and I'm not changing the business logic, right? You know, if it's one of those shortcut things in my IntelliJ or something, no issues with that refactor as you go, because you're not actually changing anything. However, we do make mistakes. So if you're touching the code that you weren't supposed to touch, what you just did is included the change that was unintentional, unsanctioned, and not agreed upon, and caught by the change detector or test. Doing that, you can cause significant problems, including the blue screens and whatever else, that was never actually covered by regression testing or anybody consciously doing it. So in some environments, they promote that type of behavior. In other environment, it's frowned upon for the very specific reason. Refactoring for readability or other things that may improve developer operations has significant risk because you can break something in the process. And I've done a lot of heavy refactoring. And I broke things. And as a matter of fact, if you're going to do refactoring right, you better break things first. So, it does have a significant problem. And people will say, well, we have plenty of tests. I don't believe that at all. I think there's always tests you can make because tests can be exhaustive and you know, there's a lot of tests that depend on the specific data. You load different data in it and it breaks. So I'd say that it needs to be a conscious decision to refactor. Because again, what does refactoring actually do? It changes the structure, the architecture, the design, it changes naming conventions. It changes. Where the business logic sits. Does that impact user value? It shouldn't, right? That's by definition. if it doesn't affect it, and the user is already happy with it, why are you doing it? What's the interest? So I learned that lesson a long time ago. One of my first few jobs, we were doing reports using XSLT transformation from XML. You're getting a pretty page for printing. And I was constantly annoyed because anytime we ran the report, there were bugs and you would always like fix a bug here. One hour, two hours, like really annoying. And. It's, it's weird because it was copy and pasted code that was duplicated all across and I finally had enough of it. So over a couple weekends, I picked it up unsanctioned, didn't tell anybody I was doing this, and I just started fixing it and I refactored it completely. The quality was great, except I didn't leave time for testing completely. And nobody knew that I was making these changes. And when it came time for me to deliver it, people were like, well, so this is where you were wasting the time. And I couldn't really explain it that I really just was annoying. and that's when I learned the lesson that you can't just do these things just because you feel the code is not perfect. You have to, even though you're annoyed, you have to bring it up and collaborate and talk about it. So you got to surface it to the top. And if you surface it enough and say, look, we're constantly getting distracted. Chances are you will be given an opportunity to tackle it because most people, most bosses are like this. Hey, don't come to me with a problem unless you have a solution. Right. I think you know, good development shops cultivate a habit of sensing when there's a need to do refactoring, right? Code spells, right? Looking at things like dead code or unnecessarily long parameter lists or whatever it might be, that it's still working. Your point is not changing the functionality, but they can make it better, right? Data clubs, things like that. Unnecessary primitive variables, So at some point, in our industry, we started getting those tools that scan the code and pop those things up and are very, very annoying. If I'm an engineer and I have to solve those nitpicking things, I hated it every single time. But if I discovered something because I was annoyed to it and I had to work on it, I'd be the first one bubbling that thing up because I want to fix it. Definitely. I agree. My team was thoroughly freaked out when I just didn't want to engage on the refactoring conversation. Even with what you just brought up, there's too much nuance to be like, Hey, Mr. Product Manager, which product? Like parts of the code should we refactor and which parts like which parts should we decide is normal cost of doing business and which parts should we decide is as much as like an enhancement and which parts is like a bug or whatever and I was like guys I was like I'm not in the code with you sitting over your shoulder I have to like I don't want to be in this discussion you tell me and I think they were thoroughly freaked out with that. Well no they made a number one mistake. Assuming that you have exactly same context, but your context is user value. Your context is not code quality, right? You rely on them to write the best code possible with the information they have. And if they failed, well, then they need to justify while. Why that specific improvement needs to be a backlog item with a tech debt label on it. I will tell you, I am this developer, by the way, with my, with the, like the code I do for the podcast and whatnot, like I'm this developer, I cannot stand. Functions, like I have, I, for the podcast, I have two functions that do the same thing. They do the exact same thing. Zoom in, zoom out. They take different variables, but they do the same thing. And I can't stand that I am too lazy to go back and refactor them. I easily could refactor them to add a little statement to say, Oh, if you got this extra variable and do this extra logic, I'm way too lazy to do that. So I completely understand the developer who says, I don't like seeing duplicate code, basically copy pasted code, you know what I mean? In different functions. I don't like that. We should just refactor this one function. it's much easier to read, to understand, oh, you're passing it to the function with these variables. So I have developers on my team. Who say like, I can't stand copy pasted code. I need to refactor it. for anybody that hates copy pasted code, that's called turbo coding from before two thousands. However, as an architect, I have to show the opposite side of it. And that's actually code isolation. So if you want to avoid doing refactoring and somebody tells you to optimize, just say, Hey, I'm keeping the code isolated so that if something breaks in one area, it does not impact another. Yeah, I mean we just talked all around the world about technical debt. I don't know if we hit any the other the only thing we didn't hit was we talked about a real early in the podcast is, is there a way to use technical debt to your benefit? You know what I mean? to use it as a scalpel, to say like, Hey, I'm going to incur technical debt in this specific area enough where I can get this strong market signal. And then maybe I'll come around in a second pass and make it scalable or something like that. We do this all the time with usability testing do you need a pixel perfect design with everything perfect, or do you just want to, Test out something that quickly works and evaluate if the users are going to use it. You know, you and I, we kind of talked about adding menu items that say, Oh, click feature coming soon. Fake door test. Yeah. Right. Fake door testing. That's another. You know, possible tech debt thing. I mean, you don't necessarily need to have a fake door. You could have maybe just small functionality and expand it later if you're so there are ways to, to test the system and test the user's behaviors. That way you don't always need to implement fully featured solution again. You know, if we were doing waterfall, we would. But we're not, we're not building something that can't be changed or it's hard to change. We're going towards the agile movement where rapid change is what we want. We want immediate feedback and we're okay getting clarity later when we'll have the ability to stabilize. I mean, how many products do you know? There are so riddle in tech debt, but they've captured the market and then built out version 2. 0 right? Because at that point you have so much tech debt that you want to do it from scratch, right? Exactly. Right. And you have the funds. Full clarity of the market and user and everything else, which you simply didn't have before. But most, most companies at that point where they're making money, they're not going to turn into development teams for the next three months. We're going to rearchitect the backend so that we can, which means, which means they didn't incur heavy enough debt. If they were running the old thing and they're running a hundred people team, right, in order to operate something relatively small, because it's riddled in tech debt. But if they re engineered it and they had a 25 man team that was able to do the same thing, I think they would reconsider. So I think it's merely of putting the picture. Now, hopefully they don't find any of anybody super aggressive. That's going to stake the claim in that and throw everybody under the loop expecting to implement this quickly. But you know, those are some of the things we've seen people do. Indeed. One last comment before we wrap up here in our discussion, we talked about applications having things that people don't see like APIs, for example, right. Absolutely applies there. So you could use techniques there as well, trying to get to market with an API that. Portions of it are and the rest of them are stubbed out. Then over a few sprints you can remove more and more stubs. You're incurring tech debt, because at that point, when you get to the last piece, the last stub you remove, maybe conditions have changed, new data sets come in, and now you're gonna possibly have to go back, right? So, yeah, and so that's also something I wanted to say. It's not just applications that are user facing that this applies in. And the other thing is, As far as refactoring, you're never really done. You're never really done with refactoring. You're always in pursuit of something better. You know, I like what you're saying about the APIs. The API debt is actually something huge. Yes. When I had a chance to Work with teams on the APIs as an architect. One of the things I saw is people implement the API so quickly. They don't give it the afterthought of how easy it is to adopt it. So they would have variables that aren't clear structures that are hard to understand. That's not what user expects. And the debt was to rebuild that API in a way that makes it easy for others to do business with you. Because that was part of the sales approach. If you can integrate quickly, you get to value quickly and that helps everybody out. So that's another form of debt. I completely agree with you. Awesome. All right. Well, thank you for the three people that have still you know, stayed with us. Let us know. Wait, wait, does he count for two? He counts for two. Let us know what you think about this podcast in the comments below. And also, let us know other topics that you'd like us to delve into. And last but not least, don't forget to like and subscribe.