Hasty Treat - Technical Debt

Welcome to Syntax.

In this Monday, hasty treat, we're gonna be talking about debt, And I'm not talking about financial debt. I'm talking about technical debt. Now technical debt is the type of thing that can really show its head in long term projects and really make you pull your hair out sometimes. So we're gonna be talking a little bit about what it is, why does it and maybe some techniques for reducing it or avoiding it. My name is Scott Talinsky. I'm a developer Denver, Colorado. And with me, as always, is the West Boss.

Hey.

Excited to be here and to talk about technical debt. Yeah. Me too. This episode is sponsored by Prismic and Sentry.

Now Sentry is the error and exception tracking software that does more than just track your errors and exceptions. It also allows you to tie those errors directly to releases Specific even, like, maybe user objects. Right? You ever have a user come up to you and say, hey. I tried to do this thing, but it gave me some weird error. You're saying, I never heard of that error. Maybe there's something very special with this one particular user's object or user account.

Well, now you could actually tie that That exception that took place to a specific user and then maybe dive in to figure out what's going on, and you can do that without having to, You know, ask the user a bunch of questions. Who wants to do that? You got all the information at your fingertips. There's also some really amazing performance tracking tools that give you a user misery score for each of your routes. I love it. It's very fantastic. I've been using it for a long time on level up tutorials.

Gives me a great amount of visibility.

So if you wanna try Sentry, which is our preferred error and exception tracking service over here at

Syntax, check out Sentry dot I o. Use the coupon code at Tasty treat, all lowercase, all one word, and you'll get 2 months for free. We are also sponsored by Prismic. Prismic is, We call it a headless CMS. The way it works is you sign up. You implement all of your data types, your fields, your relationships, all that stuff, and it gives you an API out the other end. You can pull that into any technology you're working with and use that as The CMS for your website. So what I'm gonna tell you to do in this ad read here is that you've probably wanted to try Nuxt or Next or Gatsby or literally any technology. I'm gonna say Nuxt. You wanna try out Nuxt? Well, why don't you try it out with Prismic? They Get the back end gets you up and running super quick with their CMS. So next time you wanna try it out, check out Prismic at Prismic, f. Prismic.i0forward/ syntax.

They have a whole bunch of starters there, and, specifically, the Nuxt one's gonna get Get you up and running really quickly. Thanks so much to Prismic for sponsoring.

Sick. Alright. Let's talk about technical debt. Now technical debt, Wes, I don't know how much you've experienced technical debt. I'm sure you're experiencing it to some degree with your own course platform considering how long you've been working on it. Yeah. But, typically, technical debt is a thing that comes about over the course of time in a project.

And As time moves on, when many things change, whether that's libraries get outdated or code that's been edited by 18 people With not a lot of hard standards or maybe just things change.

And over the course of time, Those changes build up into what's called technical debt, and technical debt is the term to describe, basically, Code that is going to slow you down because it is just basically stuff brittle, easily breakable Code that you don't want to work on. It's things that are are potentially, house of cards. You touch 1 card, the whole thing will fall down, so you just Don't touch it or you just start building somewhere else. Sometimes I like to refer to this as, like, a code base's quirks and features. You know, a little Doug DeMiro drop there because, like, Every code base that's been around for a long time has these little quirks and features where you say, oh, yeah. This is the case, 99% of the time, except for this one particular time, time that if you do this, the whole thing will blow up, so don't do that. And those are the type of things that that are that just really show up in in any project over the course of time.

There we'll be talking quite a bit about strategies to avoid technical debt, but it is funny. Maybe we can tell some stories along this podcast about technical debt that we've Yeah. We've hit ourselves, but it's definitely one of those things where I my brain, when I think about technical debt in code, I think about If I'm going to groan or complain when there's something I have to work on, it's assigned to me that that code has

accrued some technical debt there. A really good example is is often you see start ups coming out with amazing features, and they're moving the pace that they're moving at is unreal, And people are the end users are absolutely loving everything that they're getting, and they I'm specifically thinking about the banks in Canada. Banks in Canada are so slow, so outdated, and part of that has to do with, like, regulatory stuff and and whatnot. But, Like, one specific feature I'm thinking about is that none of the banks in Canada offer 2 factor authentication, which is, like, laughable because, like, I have I have, like, markdown notes that are behind two factor authentication. I'm just like money is not. And the reason why they don't have that is Likely because there is years years years of systems and integrated whatever and, different outlets and different ways to log in and different kinds of of, log in. And there's business accounts, and there's management accounts, and There's people that share account, and there's all this stuff that they're just like, okay. Like, it's not as easy as pushing the enable two factor authentication button as it is on A lot of these implementation is probably been in the works for years on on some of these, and that's just because they have so much Technical debt that's been built up over the years.

So it's I think it's inevitable. There's certainly things that we we'll talk about how to sort of avoid it, But these are just types of things where you've got a 100 monkeys

slamming on the keyboard all day long. Eventually, you're gonna have Some technical debt that you need to deal with. Yep. You're gonna get some rotten bananas in there somewhere. I have a, a note here that it's funny. I came up with this when I was just writing the notes. It's It's kind of profound.

Over time, any garden left unpruned will become overgrown.

So, like, If you think of your code base as a garden that you're maintaining, right, you're maintaining this thing, you're clipping it, you're you're you're you're pruning it, you're doing whatever, you're weeding it, if you don't do that regularly, it's inherently going to get crappy, so to say. And that's really the same way with your code base. Now if you never Touch the code. Does that mean there's technical debt occurring as well? Well, potentially. Right? Why? Because things get outdated. Right? Libraries get outdated. Maybe security, concerns come about. Maybe there's something that has a security concern, and then you have to update that package. But if you update a package that involves Modifying a 100 files or something? Yeah. You know, these these types of things can happen without you even touching the code. So it's not just Human error. It's just the inevitability of time marching on is going to accrue technical debt for you. I'll give you a little example,

in my own course platform so, part of my course platform, not the user facing thing. I have a whole administration tool that myself and the assistant use to Manage accounts and do refunds and and switch things over, the the whole sort of, like, administration back end. That I built that on Next. Js couple years ago, and it's it's been running fine and working great. I think it was on Next. Js 2 point o. And I think maybe about 6 months ago when we were on Next 9, I was like, oh, I wanna use some of the Next 9 features And because this will make adding this feature really, really easy, and then I hit that thing that you're talking about is, like, I didn't it's not bad code. It's it's great code. It's running fine.

But in order for me to update it to the next 9, then I had to update a whole bunch of the code because there were some breaking changes over time and Some of the integrations that I was using, and then I was basically saying, like, okay. This, like, quick little thing that I wanted to code up in an afternoon Turned into a multi no. It wasn't a day, but, like, a multi hour effort of having to go down the route of going down breaking changes in finding the documentation from upgrading to from 6 to 7, and, like, that wasn't super visible anymore because they're on I already 10 was coming out soon, and I was just like, it's kind of too bad that code just rots like that, where if you don't touch it, you literally don't do anything.

When you do wanna work on it in the future, then you have this like you said, I I had been hadn't been maintaining it, so then you've got a bit of an issue there. Yeah. Technical debt can accrue from

not updating your code while the world passes your code by, and then you have to drug through some updates. Especially in JavaScript world. Especially in JavaScript. Especially in React Router. No. I'm just joking. People always get on React Router about changing their API too much, but I love React Router. So, I I will defend their changes because all of their changes have been good. Because that's nested routes. Right? Kinda have those nested routes. It's my number one feature. Right? Take away My CSS, but don't take away my nested rods, nudge.

So it can also accrue from updating too much. I mean, everybody who listens to the show knows that I never touch my code. I never refactored, and therefore, Which is obviously a lie. I I refactor too much. And because of that, I also accrue technical debt because sometimes I have Unfinished transitions here or there where the code works just fine. But, hey, this 1 component is using this 1 specific library that maybe We were gonna spread out through the rest of the site, but never got around to it. So now we just have this 1 component that's sitting on this random Library here. Well, maybe we'll come out to it later. Maybe we'll rip it out. Maybe we'll still move everything over there.

Yeah. That's That's also technical debt because now you're you're putting things that a non standardized way, a non up to date way, or maybe a just a a none. I guess the standardized is really the one of the best ways. As long as your code is is in a standardized, you know, way to have it exist And you're updating it, then you will be less likely to have technical debt. But so, I mean, it's gonna accrue from not touching your code. Yes. Okay. It's also going to accrue from being a little bit too sporadic in touching your code, maybe too many different code styles.

It's also going to accrue from not having proper systems in place to prevent it from happening. You know what? I I have a friend who said that they have a Style lint, which is for CSS linting, a style lint rule anytime anybody introduces a color value that's not on their Specific list of approved colors because it's like, okay. This is technical debt. Too many CSS colors. We have all of the colors you could possibly need to find. You don't need another one. So if somebody brings us in, it gets angry. It prevents their PR from merging and things like that. So The standards are are big thing here. That's why people like to use systems like Tailwinds or,

just straight up variables, or really any other system where you cannot use a color or even in that thing, a padding value, because before you know it, yeah, you use 7 pixels there and 11 pixels here and Yeah. 14 pixels there. Then Things over time start to we we need, like, a a word for that. I would think it's called style drift, I would like to call it, where you start with a set of colors, and And things start to drift out of it, and then somebody uses a color picker on Firefox and puts that hex code into Chrome. And Over time, these things are not exactly the same, and I think CSS variables will probably

fix that for a large portion of it. Somebody's using a font size and pixels, and then somebody else is using RAM. And then I think I think one of the things that you even mentioned about, like, padding shifting even by a couple of pixels is is definitely one of the things that can lead to inconsistent CSS and inconsistent visual design. So it's not just, you know, over time, but if you have Just inconsistencies in your system, it's going to lead to code that is not going to behave expectedly because it's not within And and I'm I'm a huge fan of of CSS design systems overall, especially with CSS variables as a way to reduce that. And establishing those systems is one of the things that can really, really help you avoid technical debt. So what are some techniques that you can use To avoid technical debt or at least to diminish its results because this is something that's sort of inevitable, but if you are Working at it, it will be less painful. So the first one is going to be deny your FOMO of new things. Now I'm the type who does get fear of missing out, New shiny libraries and new updates and all those things. I'm like, oh, I gotta try this out. But if you deny yourself that, It can prevent you from implementing something half in. And if you implement it half in, it's it's never gonna be full in, and you're going to accrue technical debt there. So by simply just denying your FOMO and just being happy with you got you know what? You have you have a React at home. You don't need a new React. Okay. If you deny yourself that, then you you're you're gonna be a little bit more fine. It's funny. We often get questions in our Hot luck from people who are new developers, and they're saying, like, oh, the

the old developers at my work, I don't want to use, And then they rattle off everything that's been popular in the last year and a half weeks. And, like, what the heck? And there's a reason.

In most cases, I would say there's a reason why these developers don't want to, pick up literally any technology immediately, and it's because Before you know it, you've got Bootstrap and Foundation and a a mix of BEMs and throw some tailwind in there. And, like, Before you know it, you've got every single hot thing in your code base, and that's the that's the literal definition of technical debt is that you've used too much of the stuff That can end up slowing down your website, making a bad user experience for your users, things like that. And what I find in a lot more experienced developers, they will sort of n. Back and say, okay. A good example is React. Let's wait and see how this React thing pans out. Yeah. And then once React been sort of stable, and and a lot of people are using it. And there's a lot of good case studies. They say, okay. We we can start to implement that ourselves, and and that's gonna be our choice Going forward, even if something cool comes out in 3 years, we can't switch to it. We've got too much stuff. Like, I on Twitter the other day, we were talking about was it Redux? And I think it was I think it was a dev from Etsy, and he says we have something like, I don't know. 200 developers committing JavaScript code to Etsy every single day. I forget if it was that many people. It it was something Unreal. Where it's just like, okay. If you've got that many people committing code to your code base every single day, they picked Redux. Even though Redux is sort of Fell out of fashion. It allowed them to have very stringent system for doing things. It's very clear.

Even though it might take a little bit more be a little bit more confusing. With a codebase that large and that many developers working on it, you need to have some sort of standards in place and then stick to that no matter what

for at least 5, 6, 7 years. Yeah. I mean, then that's definitely, like, that's definitely a a thing. Right? Or even you'll see people respond to it, and they're like, who's still using Redux? It's like everybody is. If it's a big picture of things, everybody's still using it. You know, otherwise, you're gonna have Frankenstein's code base if you're not if you're or trying to swap out things that quickly. And and, You know, I want to talk because I do like to refactor and I do like to swap things out, but, you know, it's honestly my job to try things out. It's not necessarily your job to try them out. It's your job to make make things that are are perfect, and and I, you know, can use some of my Code base is a little bit of a playground to try them out, but I'm kind of a guinea pig in that sort of way where I'm I'm expecting there to be the pain there. Where if you're trying to build a system that lasts, it's that's not a great strategy. Another thing you can do is you can abstract code quite a bit To remove some of those barriers now, like, if you have a wrapper around maybe like a, This is gonna be kind of a trite example, but let's say there is a node email.

You're you're emailing with a node, and you have a package that you're using to do that, and that package suddenly becomes deprecated or out of date, or they're gonna say, hey. We're no longer gonna do this. We're no longer gonna update this. And, now you need to if you are worried about maybe security issues or something like that, now you need to rip that package out of everywhere you're using it. But if you were to abstract it into its own module and exist as its own thing, you'd only need to rip out where you abstracted it and replace Face that. So abstraction can be a strategy for avoiding technical debt, but it can also, if you abstract too much, It's also a strategy for incure acuring. Why do I keep saying acure?

Accruing technical debt. There you go. Yeah.

Woo hoo. Another tip we have here is don't put off refactors or updated dependencies, just because like, we saw that with, What was it? Python Python 2 to 3, was it? 2 to 3. Yeah. Where like, that was that was just a major and it took many, many years for a lot of people to and and that, I don't necessarily know that that was the issue for, like, people who wrote in Python, but if you are like, the JavaScript community, Like, you you write a line of code on Friday, and Monday morning, you have 14 dependencies to update, and I often groan at that. But I find that myself, if I keep on it, unlike my example earlier, then it's it's not that big of a deal,

especially if you have good. I'll let you I'll pass this next tip-off to you, Scott. Yeah. Good tests. Good tests help. At the very least, if you're not gonna have, like, full on unit testing whatever, Make sure that you have some baseline stuff. Like, if we use Cypress to just one of our Cypress tests is to just hit every route on the site, Just to make sure every route loads. Hits the route Yep. Checks the data attribute, make sure it loads. That's it. And if you if you do that, You're gonna prevent yourself any runtime errors and exceptions that are gonna just pop up from some library. And if you're updating minor and patch dependencies, Honestly, I I don't know if this is right for every team. Right? But I do it every week. I'm the I'm the keeper of those dependencies, And I just update those dependencies once a week, submit a PR for it, test it, and then it's in the code base. It's in the whatever. And and and, You know, that strategy hasn't burnt us that much. No. I, it's unless it's a major dependency. If it's a major dependency, We need to coordinate. Right? But if it's a minor patch, whatever, and it shouldn't break anything, well, I I usually update, make sure my test pass, and then Merge it. Good to go. Right? And then that at least keeps us up on those things. That way, there's no huge jumps in any sort of, library that we're bringing into The code base. Let's move on to the next section here, which is examples in the real world. And sometimes you can just feel when a website has

A lot of technical debt because they're not, they're not able to do things in such a way so that you sort of have to work around The limitations that you have. I specifically remember, this was years years years ago where I I was doing one of these, like, What was it? Like, a Dragon's Den kind of thing where I was me and, like, a friend were a developer, and then we had somebody else that was Had ideas, and then there was, like, a back end dev. And I remember, like, the back end dev set up this, like I don't know. It was sponsored by Microsoft. They set up some Microsoft Silly back end thing. And I remember him giving it to me, and I was like, okay. But, like, I don't need the he, like, gave me, like, the head and the foot. Mhmm. And I was like, okay. But, like, I don't need that part. And he's like, you have to have that part. And I was like, why? It's just the front end. Like, I'm I'm doing the front end here. And he's like, no. And I was like, okay. But, like, how do I how do I put my own nav in? It like, if you come with all this All these prerendered divs and everything, and I had to, like, do all these, like, workarounds where I had to, like, absolute position it over top of the stuff that that was spitting out, or You run some JavaScript to get rid of it on the client side, and that's the type of stuff that feels very technical deady to me. Like, I go to any airline website, Specifically, Air Canada, and half the links are opening in new tabs. And, if if I go to my cell phone carrier's website, it, like, has, like, 700 loaders, and then, you try to click something, and it all jumps down on the page. And it's reloading, and one thing loads, and then and then you're like, okay. It's Done. But then it realizes it needs to load another thing, and, like, that's just a faucet of a facet of Faucet. The facet. I'm trying to sound smart here, but I'm not.

It's just a facet of the sorta underlying they've had this system around for years years years, and you can kinda feel that when you use the website. That could be our our

name of our our secondary podcast. I'm trying to sound smart here, but I'm not.

I have a a a good example, a real world example of some project that I had a hand in when I got my very first agency job, And, this is the type of technical debt that me as a junior programmer, my 1st developer job, I couldn't touch this thing. I couldn't I couldn't Fix this technical debt, and there's really no point in even me trying unless, of course, I was getting, paid to rewrite the project scratch, but I had a site when when I I had my very first client. And all of our sites were were on WordPress. They were on Drupal. They were, You know, managed by the client except for this 1 client that the the company had had for, like, 10 years, and the site showed it. I mean, the site was All straight up HTML templates. And if you looked at the FTP, there was 800 folders that were like old, XX, old, Do not touch old, whatever. You know? And then if you get into the site, each page was its own HTML file, obviously, so there's no Reusability.

So if you make a CSS change, all the CSS was done in line on a page, so there was, like, no global style sheet with the exception of There was, like, 4 or 5 global style sheets, all of which were, like, overriding each other and various, and some pages loaded all 5. Some of them didn't. Some of them loaded 1 or 2. And Let me tell you. If I were to untangle this mess, it would it would not have gone well. I would have just completely scrap it and and start over from scratch. But I'm the new guy, and they're saying, okay. All you need to do is add this new landing page. So for me, I'm not gonna rewrite the site because that's not what they're asking me to do. So this is unfixable technical debt. My what I have to do is I have to take take essentially the way of working on this code base It was established before me. Alright. You just create a new CSS file. You create a new HTML file. You just dump it all on there, and you ship it. And you don't even think about it until 2 months from now when they need another page, and sometimes that's just the way it is. So not every technical, that needs to be addressed.

And does the client know or care that that website is a tangled mess of who knows what? Probably not. You know, maybe when you sell them on a new site, you can try to say, hey. This one's getting a little long in the tooth.

We don't really like working on it, so, maybe maybe we can get you a a new site here or something like that. Obviously, you wanna pitch it in a much more friendly way than that. But, you know, some technical debt is you as a developer in your day to day life, you're not gonna be able to fix it. Yeah. And you're just gonna have to deal with that. But being cognizant of it being, like, technical debt is is a positive, I think. I agree. Like, that that's a really good point I wouldn't mention mention is that sometimes You do just have technical debt, and you have to work within the situation that you have because

it's debt. And, often, it's not worth the company Redoing the entire thing just so that the developer can work a little faster. It might be it's just worth it in some cases to pay the developer a little bit more to Have to spend a little longer on the website to work around whatever specific issues. That's not the answer that a lot of us wanna hear because we wanna hear, Scrap the entire thing and and rewrite this. But at the end of the day, like, we talk about banking and airlines. Like, those are Probably have millions of lines of code that have been written. You can't just, like, refactor that sucker In Next. Js in the afternoon, they posted the Hacker News.

That's that's a massive, massive rewrite. Yeah. New developers do need to know that, older developers are not always Just lazy for stuff like this. They there are some specific very good reasons that we've been around the block, and we've we've tried to either do refactors like this, or we know Flat out that it's just not worth it. I'm a huge proponent of refactoring, testing, keeping everything up to date as much as possible, but sometimes you just gotta ship it. And, That's that's what I'm about sometimes too. So I get it. And, if you're feeling the weight of technical debt in your code base, You got a couple options. You can fix it and work hard at fixing, chip away at that technical debt before it turns into a giant mountain While it's still a molehill, you can get rid of it a little bit, or you can just, accept it as being the code base's quirks and features and And say, this right here is is this is the CSS module here. We don't touch this 1 or else the whole thing will turn blue. Who knows why? Can we maybe do a call in show where we act like Dave Ramsey

and pea how people call in about their technical debt? Yes. Hello. We've got Dave calling in from, Arkansas.

You what's this? You've got how many WordPress sites? Fourteen WordPress sites.

Oh my god. Alrighty. So we gotta get on the snowball.

1st, start with the the smallest WordPress site first. Well, we'll we'll give him we'll give him some snowball for Hey. Hey. Can you give him some Snowball for free?

Oh my gosh. We should do that. Oh my gosh.

We'll get him on the syntax plan.

Oh, yeah. Alright.

Better than I deserve.

Anyways, I think that's all we have for today. If you've got any tips about your technical debt, Make sure you tweet us at syntax f m. We would love to hear your stories about how you fixed your technical debt.

Anything else to add there, Scott? Nothing at all. But yeah. Yeah. You got options or not. Who knows? Depending on your code base. But that's it. That's all I got. We will catch you on Wednesday, when we will be bringing to you a potluck episode, where we're gonna be talking about some fun stuff. I we had so many good questions here. So we we We ended up doing 2 potlucks in a row, and and they're fantastic questions. So, tune in Wednesday when we have a pollock and we answer more of your Peace.

To subscribe in your podcast player or drop a review if you like this show.