Hasty Treat - Technical Debt

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

In Next. Js in the afternoon, they posted the Hacker News.

have millions of lines of code that have been written. You can't just, like, Oh my gosh. We should do that. Oh my gosh.

Probably been in the works for years on on some of these, and that's just because they have so much

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 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 Woo hoo. Another tip we have here is don't put off refactors or updated dependencies, 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 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, 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, Hey.

Peace.

You what's this? You've got

We'll get him on the syntax plan.

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 accept it as being the code base's quirks and features and And say,

Arkansas.

how many WordPress sites? Fourteen

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.

and pea how people call in about their technical debt?

Wednesday, will become overgrown.

WordPress sites.

tune in Wednesday when we have a pollock and we answer more of your

Better than I deserve.

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

that are gonna just pop up from some library. And if you're updating minor and patch dependencies, 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 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, and technical debt is the term to describe, basically, Now Sentry that 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,

We need to coordinate. Right? But if it's a minor patch, whatever, and it shouldn't break anything, 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 this right here is 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 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, 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, 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

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, CSS and inconsistent visual design. So it's not just,

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 questions. So, 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 file, obviously, so there's no Reusability.

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,

this was years years years ago where I I was doing one of these, like,

The limitations that you have. I specifically remember,

how do I put my own nav in? It like, if you come with all this

you try to click something, and it all jumps down on the page. And it's reloading, and

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

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

if if I go to my cell phone carrier's website, it, like, has, like, 700 loaders, and then,

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

facet. I'm trying to sound smart here, but I'm not.

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 pick up literally any technology immediately, and it's because

Specifically, Air Canada, and half the links are opening in new tabs. And,

it's debt. And, often, it's not worth the company we can't switch to it. We've got too much stuff. Like, I on Twitter the other day, we were talking about is probably 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

We don't really like working on it, so, now you need to

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.

And does the client know or care that that website is a tangled mess of who knows what? if you are worried about 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.

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 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, So if you wanna try Sentry, which is our preferred error and exception tracking service over here at

it's inherently going to 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 don't do that regularly,

just straight up variables, or really any other system where you cannot use a color or even in that thing, a padding value,

anybody introduces a color value that's not on their Specific list of approved colors because it's like,

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

Those changes build up into what's called technical debt,

just basically 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.

you don't want to work on. It's things that are are potentially, 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,

easily breakable of time marching on is going to accrue technical debt for you. I'll give you a little example, name of our our secondary podcast. I'm trying to sound smart here, but I'm not.

And over the course of time, 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,

stuff that needs to be addressed.

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, As time moves on, when many things change, whether that's libraries 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 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, 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?

With not a lot of hard standards or maybe just things change.

brittle,

house of cards. You touch 1 card, the whole thing will fall down, so you just

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.

In this

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 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

Tolinski.

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.

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 Code that is going to slow you down because it is Code New shiny libraries and new updates and all those things. I'm like, oh, I gotta try this out. But Welcome to Syntax.

Monday. Monday. Monday.

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.

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, Excited to be here and to talk about technical debt. Yeah. Me too. This episode is sponsored by Prismic and Sentry.

Gives me a great amount of visibility.

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.

Boss and Scott El Toro Loco

soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes Barracuda

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing,

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.

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 When you do wanna Oh, yeah. Alright.

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

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

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

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 if you abstract too much, It's also a strategy for incure acuring. Why do I keep saying acure? well, I I usually update, make sure my test pass, and then

Accruing technical debt. There you go. Yeah.

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, Monday, hasty treat, we're gonna be talking about debt, 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 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

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, around maybe like a, this is something that's sort of inevitable, 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

This is gonna be kind of a trite example, but let's say there is a node 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 get outdated or code that's been edited by 18 people that's just the way it is. So not every technical,

if you have a wrapper

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 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.

system around for years years years, and you can kinda feel that when you use the website. That could be our our

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, 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.

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 email.

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 Denver, Colorado. And with me, as always, is the West Boss.

And, this is the type of technical debt that

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

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

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,

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.

Bootstrap and Foundation 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 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,

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

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, 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

stringent system refactor that sucker tool that myself and the assistant use to 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,

even if something cool comes out in 3 years,

years years years of systems and integrated whatever and,

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 for doing things. It's very clear.

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

Technical debt that's been built up over the years.

Likely because there is

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, 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,

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,

just because like, we saw that with, It's just a facet of the sorta underlying they've had this

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, Yes. Hello. We've got Dave calling in from,

is is definitely one of the things that can lead to inconsistent

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,

the old developers at my work, I don't want to use,

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

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 if you if you do that, You're gonna prevent yourself any runtime errors and exceptions

if you deny yourself that, It can prevent you from implementing something And you're updating it, then

you know, way to have it exist Probably My name is Scott.

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.

in my own course platform so, part of my course platform, not the user facing thing. I have a whole administration

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 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 very technical deady to me. Like, I go to any airline website,

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 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

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