over the past 10 days or so i was fortunate enough to go on a vacation for my 10th anniversary with my wife and um we went overseas we went on a on on a fairly long trip and uh this by the way is why there wasn't an episode last week i was out of the country and uh we had a great time we came back and um we realized just how tired jet lag can make us and it seems to be this compounding problem where we try to get a little bit of sleep here and there but then we're putting off the things we have to do to get back into our normal lives which makes us even more tired and run down and feel like the sleep that we are getting is actually trading off it's making things harder when we are awake now not to be a debbie downer but this is all a lesson that we're learning about jet lag but it's also as i was thinking about it on the ride home on the flight home i should say it's also a good allegory uh it's very comparable to what we experience with tech debt now if you think of tech debt you probably think of that code that you wrote uh that you didn't cover with tests or maybe there is a migration that you know you have to do maybe it's an old version of something that's insecure and you've patched it but you haven't really done the full upgrade that you need to do i'm sure i'm triggering a lot of concerns for you right now by just mentioning that code that you wrote that you didn't cover with tests tech debt and it turns out there's also a lot of uh a lot of literature a lot of blog posts a lot of people talking about tech debt because it seems to be a pervasive problem something that we do to take on what we're calling debt in order to pay for something in the short term that we have to pay back later and the interesting thing about debt is that it has a very clear cost when we take on debt we know exactly what the risks are of that debt because they're outlined in some kind of term sheet some kind of terms of use or uh you know the fine print we can read all that we know the percentage that it's going to cost in the future but this isn't the case with tech debt we don't know exactly how difficult it will be to pay down tech debt we don't know how much it's going to cost there's a lot of uncertainty imagine that you're talking about a lot of uncertainty imagine that you're talking about a lot of uncertainty imagine that you're tech debt is from a lender who is deciding to not be upfront about the interest rate. They're not being upfront about the repayment period. They're not being upfront about the impact to your credit, for example. They're not even being upfront about how much credit you are even allowed to take. At what point does that credit run out? Where are the lines drawn? This is more like what tech debt feels like. So perhaps a different analogy would be better. And so this idea of jet lag. If you're unfamiliar with what jet lag is, the basic idea is that when you travel from one part of the world to another part of the world, you're traveling fast enough in a jet near the world. The speed of sound that you arrive in a place where normally for you, it would be six o'clock in the afternoon, but it's midnight when you arrive in that place. And then when you return, the same thing happens, but in reverse. And for most people, this is obvious, but it has so many interesting correlations to what we call tech debt. For example, we don't really know what the effect is going to be on our bodies when we travel. We don't really know what the effect is going to be on our bodies when we travel overseas. How long will it take us to clear that jet lag? For example, when we arrived home, it's taking longer for my wife to feel back at the normal time of the day. There is some adjustment period and there's research done about that adjustment period, but it by no means is explicitly clear when you go overseas exactly what that repayment period would be for you. In order to get back to normal, how many days will it take? And what exact procedures should you follow? This is different from person to person, from situation to situation. Similarly, in the time between when you arrive at your destination, and when you have kind of adapted to that new situation, there is a period where you're not really feeling at your best. That is kind of that lag, Similarly, when teams are used to one situation where they've taken on that, you know, they've done that shortcut process in order to accomplish some particular strategic or tactical goal. But then they try to shift into a new mindset where they're paying down that tech debt, as we've called it, where they're trying to, you know, go back and, you know, fix those shortcuts or do it the quote kind of full way. There's a period where there is a lag and then the muscle memory isn't there to write those tests. Or maybe there's some context that's missing that you have to go back and dig up. There's a whole host of things that would cause the repayment period, that lag time, to feel suboptimal. So it's not as simple as doing a different kind of work, necessarily. And in fact, there may be a personal level toll. Your individual contributing team members may actually feel frustrated or tired, worn out by this process. Not to mention, even though you're paying down one kind of tech debt, even though you're experiencing one kind of lag, it's possible that you go on another trip, that you take on more tech debt, that you have to do another round of lag. And so this cycle could continue feeding itself and creating fatigue on the individual contributors. And the important thing here to recognize is that it's not a simplification. It's a multiple transaction. There is some variable unknown cost that you're accepting. This lag period is individualistic and difficult to predict. Your situation may have longer lag. That repayment of the debt period may be highly unpredictable. I'm going to call this concept tech lag rather than tech debt for the remainder of the episode. When you choose to accept tech lag, you're going to have a lot of pressure. tech lag, you recognize that the size of that difference that you are choosing to accept, in other words, if this is a major shortcut, this is similar to a trip that's all the way across the world, versus a small trip, a short trip may have much less tech lag. A short or smaller shortcut may not be as painful to adapt from. This is especially true if you are adapting between those trips, if you don't overlap the tech lag. It's also especially true if you're only doing small bits of lag at a time, multiple small bits of lag versus one large lag. Now you'll notice that the concept of debt, tech debt, doesn't really fit this construct. Very well, whether you take all of the tech debt all at once, or if you combine little bits of tech debt and delay in between, doesn't really make as much of a difference. If we, instead of thinking about this as kind of an accounting process, where we say, okay, the tech debt is in this category of work, and then our normal feature work is a different category, right? Instead, think about this as a forced adaptation process. You're adapting your work from one set of criteria to a different set of criteria for the same outcomes. And this adaptation creates a type of drain, a type of lag on the individual contributors. It creates that for the team, because it requires some re-encoding, some rethinking of already established models, already established concepts and domains. That lag, is unpredictable. And going back and revisiting the same concepts, it's unpredictable. This is especially true because this type of work, this way of thinking, you know, with shortcuts, et cetera, and then going back and saying, well, we no longer want to use those shortcuts. It requires the engineering mindset to shift. It shifts from an economic mode, where you're okay with making these sometimes very large trade-offs. And then in the lag period, you're saying, well, no longer, we no longer want to take those, those big trade-offs. We want to go back and do it a different way. Now it's particularly difficult because you still are making trade-offs, but you're changing where the trade-offs are being made. And so now the engineer is rebuilding the same thing with a different set of trade-offs. When they've developed a mindset and a muscle memory for a different line, a different set of trade-offs. And so that's where the lag period comes from. Adjusting the mindset from one set of trade-offs to a totally new set of trade-offs. The trade-offs are in effect, the time zone shift or the shift of the daylight. And doing this too often creates a difficult environment. To develop intuition. Because as engineers work on a team long enough, they develop an intuition for where the, where is the line of quality? Where is the values that, that we derive our line of quality from? How much do we invest in making this good? Now you might say, well, of course, we always want the highest quality, but this is a virtually impossible value to have because any, any company, any company that's going to be able to do this, they're going to have toension the evolution of evolution evolution evolution evolution evolution evolution evolution consciously takes on some kind of tech lag, they are accepting that the quality for that tech lag is going to be diminished. Now, how do we decide that that's okay? Well, we determine that a certain level of quality is necessary, but anything above and beyond that is wasteful. It's not economically viable to continue investing in quality because of some other factor. Let's say, for example, timing, timing the market, or maybe we're trying to learn more with faster feedback from the people that we're working with, from our customers, from our users, and investing any more in the quality just to throw it away may not be worth it. And so we're taking shortcuts in order to test and iterate quickly. Well, these are all valid business reasons to not invest in quality. And so as engineers understand the level of quality, that is standard for the team, they develop an intuition. But if the team is constantly saying, well, we're going to change where that level of quality is, where our line, our standard line is, that intuition becomes very difficult to develop. The symptoms of this generally is a team that is constantly asking for more clarity about requirements. Think about this. You've probably experienced this, whether you, whether on the engineering side, or maybe on the product side, maybe on the engineering manager side, you've probably experienced a team that was asking and always saying that they didn't have enough clarity from product or that they didn't have enough clarity on the requirements. What do we have to get done for this? And part of this is because if you don't have an intuitive understanding of where the line of quality is, then you need someone to draw that line very clearly. Now, this is not to say that, you're kind of let off the hook and you don't have to write any detail if your team has developed this intuition or anything that, you know, any project that's not actively taking on tech lag, you don't have to invest time in creating clarity. That's not at all what I'm saying. But what I am saying is no matter how much you invest in that clarification process, a team that is constantly changing where their line of quality is drawn, they're going to constantly, constantly be in that state of lag. And so if they're in that state of lag, they need more input. They always are going to need more input because they don't know if that line is going to change tomorrow or the next day or perhaps next week. So here's what I recommend you do. I recommend that you change your mindset from thinking about tech debt as a category and instead think about tech lag. As an adaptation process for the people doing the work. Tech lag is an adaptation process for the people who are doing the work. There's no such thing as tech debt and there's no such thing as bad work versus good work. It's all about setting a standard of quality and trying to avoid the thrash of moving that standard around all the time. Moving that standard around all the time. Moving that standard around all the time. The standard of quality around creates tech lag. If you re-encode this concept of tech debt into a new concept of tech lag, you'll begin to understand better how to approach going back and shifting your standard of quality for a particular part of the software. By the way, this is also true about any kind of change in that standard of quality. It doesn't have to necessarily be that big trip style where you're going back and redoing a part of the project that you took on a shortcut for and now you want to redo it and improve the quality. It also applies to a team that's constantly trying to increase the quality level of their work. This kind of endless treadmill style of quality means that each member is never going to understand whether or not they've delivered high quality enough for the project. If they're on this constant quality improvement treadmill and keeps on increasing in speed, they won't ever know if they've gotten up to speed. This concept of tech lag, it applies whether you're taking on tech lag all at once or if you're constantly creating tech lag on your team. The same could be said for decreasing the quality. Constantly making new concessions that decrease the quality over time on team. The effect of this is feeling like people are wasting their time just to stay at the quality level that they had already previously adapted to. And so the quality will kind of flywheel in a degradation spiral downward because if they see the quality degrading in one area, and then another area, if it's constantly going down, then they may feel like it's the standard to make concessions anywhere they feel like. So the homework here is to re-encode the way you think about tech debt. Now, this is not necessarily saying that tech debt is a bad concept that you should do away with it entirely. But instead, imagine whether tech lag applies better in your situation. Does it create some... feeling of fatigue on the team? Thanks so much for listening to today's episode of Developer Tea. If you enjoyed this episode, please go and join the Discord community, developertea.com slash discord, and subscribe to the podcast right now, whatever podcasting app you're currently listening to. We will be back with more episodes. Hopefully, we're going to go back to our two-a-week schedule. The past couple of months, we've been in a bit of a period of rest. I guess it's been sort of since the beginning of this year. But rest assured, this podcast is not going anywhere. We're going to continue making episodes at a rate that is around one to two episodes a week. We'll see what it shakes out to as we move forward into the future. But please subscribe if you enjoyed this episode because there's going to be more coming very soon. Thanks so much for listening. And until next time, enjoy your tea.