Even the best code begins to look dated and inefficient given enough time. Techniques change, libraries evolve, and new capabilities replace old hacks. Technical debt is a consequence of programming that cannot be escaped, but it can be managed and accounted for. Today we’re looking at tips to avoid taking on undue debt, and addressing the debt in your repositories.
Followup Resources
- 99 Bottles of OOP by Sandi Metz
- ADR GitHub Organization
- All the Little Things by Sandi Metz at RailsConf 2014 (video)
- Architecture decision record examples for software planning, IT leadership, and template documentation
- Documenting Architecture Decisions
- Get a Whiff of This by Sandi Metz at RailsConf 2016 (video)
- JavaScript — Short Circuit Conditionals
- Lava Flow software development antipattern
- Refactoring: Improving the Design of Existing Code by Martin Fowler
- Stop Writing Code Comments
- Technical Debt Is Like Tetris
- What I’ve learned by doing The Gilded Rose Kata (4 refactoring tips)
Transcript
The following is a machine-generated transcript of this episode. It will contain errors until it has been reviewed and edited, and we apologize for the difficulty that may cause for screen readers. Do you want to help us speed up our transcribing process? Consider sponsoring an episode.
Hey everybody, Michael here. Before we get started with today’s episode, I just wanted to stop for a second and let everyone know how much we appreciate you tuning in every other week to listen to The Drunken UX Podcast. It means a lot to us how many of you have joined us on this journey for the last year and a half, and regardless of whether this is your 38th episode or your 1st, we think you’ll enjoy what’s to come in the next half of season two. If you’ve been enjoying the show, there is one quick favor that I’d like to ask. Stop for a second in your podcast app, and take just a moment to hit the like or share button. If you’re feeling really squirrelly, leaving us a rating or review is a great way to help others find the show, and it only takes a minute. That’s it! Thanks for your support, and here we go.
Clever intro comes in here where Michael says something about Michael being a host and Aaron being one of the other hosts and then a conflict of interest about whether we should be called co host or just hosts or how that should work. But either way, Hey, everybody, welcome to the drunken UX podcast. I’m your host Michael fienen.
You’re not supposed to read the words verbatim.
Well, if I if you would write me a better intro at the start of this. I can run with it. But
you said it’s Alex,
you through all of the show notes together and I’m just going to work with so don’t don’t blame me on that.
Other hosts Aaron
Hill, how you doing? I’m all right, I guess Oh, wait, were you asking them or me?
Guess you because they can’t answer now.
They can answer later. Let everybody know. Everybody let Aaron know. How you doing in two weeks? Yeah. Let’s see. That was the greeting. Now do a sponsor shout out. So everybody. If you’re looking for a map, go step by new cloud. com slash drunken UX. You can check out their mapping software. They are beta testing a new product that they’ll be debuting soon, which is a Braille based 3d printed for accessibility stuff. Very neat. I saw a picture of that. Yeah, yeah. It is really cool. They it was shared out on Instagram and stuff. So yeah, check that out. That’s kind of neat. New cloud.com slash drunken UX. If you’re looking for us,
too bad. Yeah, we’re not here. I
don’t know what to tell you about that. I go by. Just all the places twitter facebook driven UX, Instagram, drunken UX podcast. slack is drunken ux.com slash slash slack and jump in there and chat with us. We’re all those places. Maybe someday we’ll do a live show and like pull up slack or something and and do something that way. That might be a neat idea. I don’t know. brainstorming.
I wanted to give a special shout out to Chris Wimmer. I think I said the name right. Hopefully, apologies. I didn’t. Who wrote us and to just say that he’s found the so helpful with this college courses, which I think is super awesome. is why we do the show. I guess.
That’s a Yeah, if you’ve found the show helpful, let us know. If you don’t find the show helpful. Let us know. We’re always interested in in whatever feedback actually somewhere I’ll share it out. There’s a survey you can get to where you can give us all kinds of feedback about you know, whether it’s show length or tone information, things like that. So I’ll get that link out there. Uh, let’s see. What do you got in your glass? I can’t tell Oh, it’s it’s getting warmer. So
I’ve got a vodka tonic.
Oh yeah, it is it’s this room is just a hair warm Kansas has gone from nice to brutal very quickly because it’s Say that again we’re drowning you know basically add Wow, it’s hot. And so now the humidity is through the roof.
Did you get turn tornadoes like Oklahoma?
We had a small tornado here on the south end of town. The little one that was little but I’m there’s some damage. So.
Okay, Kansas, what can I say? You know what they say? If you ever see a small tornado, it’s really important to look around and find the larger mother tornado and make sure you don’t walk in between them or it will charge you
and that is actually a fact I can Yeah, I can guarantee you are in that in
Boy Scouts.
Don’t don’t get between a child tornado and it’s debris ball.
Yeah.
Let’s see I’ve got I’m I was indecisive tonight. So I brought like part of my bar in here with me. I’ve got 46 I only had like one glass worth a baker’s 46 left. So I’m finishing that and then I’m like, I don’t know what to go through next. So then I brought in a bottle of runs the Kappa xo rum, but like maybe I don’t want rum. And so I grabbed a bottle of high West distillery. Bry right bourbon. The bottle for this is is gorgeous, though. It’s like I say it’s kind of bespoke glass. Oh, this is with like a funky like the base of it. Like the glasses all weird.
Yeah.
Like bubble is it’s kind of like an old school bottle, like you would see from like an 1880s saloon or something. Right? It has those little imperfections to make it look like it’s handmade. But that’s a buddy of mine brought me this from Park City, Utah. Who and it’s Yeah, it’s it’s actually very, it’s quite good. But we’ll see. I’ll switch to one of those sometime. At some point. Uh, let’s see. Notes. Yeah, yeah. Oh, so so I sent you a link to a funny tweet. It was not funny. It was.
Your response was?
I don’t, you know, some people just like to do click bait. Let’s just start started that way. So this tweet was I think you saw it from Java. Right? It was Java, Oracle, Java retweeted this article from a guy named Brian Orlando, I’m sure. I’m sure he’s a great guy. And Brian, if you ever hear this, I have nothing against you. He wrote an article called stop writing code comments. To which I immediately said know
what like, okay, like, the intent of his article is far more sensible than the title is. And we’ll actually circle back to this later, because it’s kind of related to one of our topics. However, I think he deserves all the rinsing that he got for that stupid title, click Beatty title.
It’s because I mean, he has a point that he gets to throughout it, which you know, is this idea that some people use comments as a crutch, they will overcome it code because they’re trying to explain something that wasn’t well written. And that is true and fair. And I have seen and I have written some of that at some point in my life. Sure. The approach to the topic was not done in a way that I would have found helpful. As a learning developer. It was very chastising, and well, and I mean, frankly, while I kind of agreed with the big picture point, I agree with a lot of the smaller points that were sprinkled in as salt throughout it.
Yeah, the one the one point he does, he quotes, some, or was it Ron Jeffries? Is someone and he said, Uh, oh, code, never lies, comments sometimes do. his point was like, you can change the code and change the functionality of the program, and not change the comment. And the code is none the wiser. But now you have a rotted comment. But like, I mean, just maintain your comments. Yeah, I mean, I don’t know,
comments will always be useful. Yeah, I find it to be a good thought process, as I’m writing code, because it keeps me honest, especially if you’ve got a lot of loops that go back and forth, or things like that. Yeah. You know, if you’ve got code that isn’t self documenting, like, you know, if you’re writing Java, you can generate Java docs and stuff off your comment. Yeah.
That’s why I thought it was funny that Java would retweet that because they they invented Java Doc, like, that’s,
yeah, um, you know, the argument is that, obviously, your code itself should be readable, that, you know, it should be self explanatory to be able to look at it and know what it does. And I mean, that’s true, I guess. But the reality is that programmers, as they especially get better, their technique changes, they abstract things, you know, they can reference stuff. And while Yes, you can always make this kind of argument that will the abstraction should be named the right way or wherever, there can still be a lot of hidden stuff there. But more importantly, not having that becomes detrimental to code as a learning tool, in my opinion.
So there’s, there’s two things that my to me immediate reactions to the to like the idea of not writing comments, or the comments are bad. And this is actually like a sentiment that I’ve heard from other developers. Usually, I don’t want to say newer, but I don’t know. I’ve just other developers full stop. I the two things that I think are important about comments or one comments are readable. Like, you know, I mean, you should be writing comments that are like language, like reads like a sentence, etc. And the reason that I like that is the examples he gives, they aren’t bad examples, like you can read them and be like, Oh, yeah, I can figure out what this does. But you still have to parse it, you still have to process it. And that’s like, that’s cognitive load. When you’re reading, it’s like, I while ago, I was complaining about people who use emojis in place of words, that that is not the kind of processing because you have to contextualize what the emoji means in that place of the word. Whereas with a word, we, we have short cutting stuff in our brains, that just allows us to scan it more easily. But with with code, like, I can look at line of code, I can fully understand it, but if it has a comment above it that says something like, process employees based on status, like I can see that and it’s like, okay, cool, like, I know, basically what this is supposed to do,
I also find that it helps break up the flow of code. You know, especially when you’ve got a lot of nested, you know, indented loops and stuff like that. Sometimes midway through, it can become difficult to know if you’ve jumped into something new or not. I like having comments above functions and things like that, simply because visually, it gives my eyes a way to break up the flow of things. Yeah,
yeah. So you know that, like you’re in a different always you should be in a different method. Right?
Yeah. Because otherwise, we have a habit of like smashing, you know, run on code basically, is kind of what we end up with at that point. And there’s something there’s almost like it gives your code to timber almost. Yeah. to it that lets that makes it easy to follow along and know when you’re in and out of different things. And I have one actual big argument for this, that isn’t tactical at all. Okay, it’s that most, not most, that’s a very unfair thing. I mean, say, there are some programmers out there who are fantastic programmers, they are terrible communicators. And learning the process of writing clear, concise, good comments, to me is an exercise and communication that I think a lot of people would benefit from.
Yeah, I and I think, curbing On that note, sometimes, you may have, you may have gone through this full, like build this like magnificently amazing tower in your mind, concepts and abstractions, and everything else. And you’ve written some really awesome code. And it’s completely apparent what it does to you. But someone else who maybe didn’t go through all that thought process and do all that code, spelunking, they may look at it, and it may not be as obvious. And more importantly, sometimes, especially when you’re dealing with legacy code bases, which kind of segues into our topic today. Sometimes you have to decode spelunking, and you have to do a response or like a modification to the code that maybe isn’t the best way to do it all things considered. But it’s the way you have to do it because of how the like the existing code is, and like making the change that would be out of out of scope for whatever you’re doing. And so having a common can say, like, I’m aware that this is not the best way to do, but this is why I had to do it. And then you can reference, you know, like, a, an explanation of what’s going on. So the next person who comes back to that can wait can see, you know, your thought process of how you got to that point,
that the idea basically comes down to this thought that the only thing that matters in code commenting is the what, which is just patently wrong. The y factors in heavily to that, for instance, you know, if you’re writing code, you could write code that very clearly sets, you know, an active state on some property of a product object to false. But if you read the code, it’s like you Okay, I know it’s setting it to false. But why would you set that to false here? That doesn’t make sense that that shouldn’t be false? When the reality is, there is a reason for it. And there is some business decision that comes into play at that step of the process that knowing Yeah, what the code is doing isn’t the useful part. Because what will happen is somebody is going to look at that code one day, there won’t be a comment saying, Here’s why this is happening. And somebody’s going to delete that code out. Because they’re gonna be like, yeah, this shouldn’t be here, I can’t
figure out why it’s there. And another beef he has, is he says, not to write to do comments. And his reasoning is don’t write to do comments, instead, maybe just do it. I think I understand where he’s coming from. And I think that, instead of doing that, the better thing to do is to when you identify something, if possible, go to your repository or bug tracker and write an issue for it. If you can’t do that, then write the to comment and then write the issue for later. I don’t think doing unrelated code changes to whatever scope issue you’re doing right now. I don’t think it’s always wise to do because you want to keep your commits to be focused. And I’m kind of guilty of doing unfocused commit sometimes myself, because it’s just easier. But I’m trying to be better about that. And I think that sometimes you’ll notice things like code that has to be changed. It’s unrelated to whatever you’re working on just just happened to catch and
like to do comments, and I get it like, that’s one that I certainly can see. Like, yeah, let’s maybe not put that in a comment. I agree, tickets, probably the best way to go. But the other side of this is the way you think, is a programmer who’s doing his own stuff versus the way you think, as a programmer as part of a team, all of whom may be working on the same thing, that that do stuff could be very reflective of a signpost for the next Dev. You know, if I’ve got a junior dev who was following up behind me to do some other work, I might leave that there for them to be like to do, let’s, you know, let’s add these parameters to this to, you know, modify the query. And I’ll put it there so that when they open up that file, that you can see exactly where you know, to do you know, you 17 is this, and then they know they don’t have to hunt for it. I’m helping them out at that point. It’s Yeah, it’s kind of a very mixed feelings on it. And I he goes on, like, at the end of the article, he kind of has a little Mia culpa statement about, you know, he understands and, and I get it, I agree. The message is stop writing bad comments, but also stop writing articles with clickbait titles and people over the state,
Oh, I should, that’s your totally
your title of your thesis. And I’m gonna complain the same way about a CNN or Fox article that starts with something like that as I am this. And that’s the lesson, right? Give me a good headline. But don’t stop writing comments. Just write the right comments. Right, good comments, right, productive comments, write comments that explain things the correct way and maintain them afterwards. Right. Think that’s the lesson.
I’m so gonna say that right now. Exactly. Right. The second way to do it. Okay. You’re not saying anything reply. Stop reading so many comments of commenting on that with stop writing clickbait titles. Full stop.
That one, I’m sure that won’t get us into any trouble at all.
It’s under my personal name, I take responsible for my own comments. No pun intended.
So this actually was a good sort of auspicious timing topic, because it does, though, land into today’s topic, which gets into how, as a developer, you plan for and deal with technical debt as you work on something. And so you know, comments kind of factor into that, because comments deal with understanding your code and why it was done, what was done. And so it’s that and much more, so to speak.
Yeah, I’ve been kind of, I wanted to do this topic. Because I’ve been have this this year, I think maybe the last, the last year total, I’ve been kind of reorienting my understanding of legacy code. I’ve been learning more about formal refactoring, and about the good and the bad side of technical debt, and just all these things that I think any, you know, career developer will ultimately we’re in themselves.
So like when you start up your software, and it says, Hey, you owe us $10,000, for this last year of service. Is that what you’re talking about?
Yes. That is actually the correct definition of technical debt. It’s, it’s great that I guess we’re done. Thanks. We’ll see y’all next time.
define it to make the show longer.
A definition that I like, and I feel really bad because I did not think of this, but I can’t remember what the source was. So this is not my thoughts. But I don’t have the source was gaining developer gaining developer velocity at the expense of maintain ability. So you’re writing less than optimal code, because it ships quicker, which sometimes sometimes makes sense, you know, if you’re in like a heavy competition market or something like that, he needs to keep shipping code quickly. Sometimes that makes sense to do that. I, you had a different definition. I which I think is all that I don’t
like that one so much. The definition I use is the cost associated with the maintenance overhead created over time, due to development decisions that might be made differently at a different time or under different circumstances. The reason I like mine more, is because I don’t think technical debt is always caused by making a choice between speed and maintain ability. I completely agree.
I mean, I think that it has multiple, definitely ass, and I think yours is definitely valid to,
I think back to all kinds of things, but it’s like, overtime code changes, maybe libraries change, maybe the purpose of a tool changes or is enhanced. It’s like, there’s just, there’s so many things that can play into that, that over time. You look at code, and you’re like crap, this is not good code anymore. I think about WordPress, you know, WordPress is moving very quickly these days. And so I think I think was jetpack actually recently announced, the latest version, I want to say, doesn’t support pot, anything less than 5.10? Wow, I may be wrong on that. Don’t quote me on that I’m going off memory there. But, you know, they’re doing that in part because they’re saying, you know, what, we don’t have to worry about any of the old stuff, we can just cut that code off and go. It’s a smart
guy. In this way.
It’s a methodology. And some people like aggressively cutting stuff off. God knows, you know, we’ve argued that in browser version support for a long time and just saying, you know, what, we’re not supporting I 11. I don’t care. But code is kind of that same way, in general, that over time, it just, it builds up. And at some point, you look at it, and you’re like, yeah, I’m gonna have to spend five hours working on this to make it better. And even whether you’re working for yourself or for a company, those five hours are debt, they are time, debt, and time is money. And so it all has a cost associated with it.
I think I think one more definition might be technical debt is the additional friction created when you try to add features. And so or rather technical that the thing that adds that friction, when you’re trying to add feature left side, we want to add a
an Advanced Filter on a search form. And so we just want to add this other category. And the problem is that your categories are done in plain text. And they didn’t, for adding others, you know, so they are key, yes,
yeah, that’s a great example. You’re like, Okay,
well, we can do it. But it’s not as easy as just adding key three, you know, we’re gonna have to change the way we index those values and update the existing values so that they’re keyed. Now, that kind of that’s maybe that’s not a great example, but it’s the point across.
So that kind of leads into this, the first part of our show tonight, which is legacy code, and some definitions that I think we both put these together,
I’m I’m responsibility for this. You know, diversity, we hope you take it.
I think I think these are actually from Martin flowers refactoring book. And these are code that was here already, code that I didn’t write more code that I don’t remember writing, or code that has rotted
in code that drunk me wrote.
code that drunk you wrote, is probably the best code you’ve ever written. The
saddest part of that statement is how true is
it’s a Barber’s P. I, oh, yeah.
I have gotten up in the morning more than once and looked at something I was riding at 2am drinking scotch, and I looked at it been like, Ah, hey, that’s something.
I remember one time when I when I was at Cornell, I I worked there for almost eight years. And it was a few years and I pulled up some code and I was just like, Fuck, man, wrote this. I never get the death. Fuck, it saves me three years Pryor It was like,
Oh, that’s, that is something that that’ll make you feel older than thinking about how old Jurassic Park is, let me tell you. The other the other way to look at it is like code that has started to rock. It may not be rock. Yeah. But it has started. Or the the edges are nowhere. Or it’s maybe like a you know, an aged steak. You know, it’s, it’s, you know, aging a steak is just kind of letting it sit out and dry rot for lack of a better term. But it’s still good for a while.
It’d be like, having WordPress theme that’s, you know, version 4.9 or whatever came right before 5.0. were they using Gutenberg? Like, you know, it’s still basically valid and works but a little harder to maintain Now that everything is moving towards towards by least
you got into a fight over here on Twitter. I didn’t look at When was this?
Oh, it was enough if I
waited into thing anyway,
it was a it was a friendly discussion. There was some just someone had said
earlier this spring it looks like yeah, NZ woman.
Yeah. So she had posted the the meme of the Canaries me saying that? I don’t know, I don’t I don’t watch the Simpsons. Oh, from Game of Thrones, the Mother of Dragons. Anyways, this though, it’s the one of her making that like smirky face. And then the caption is, when someone new joins your team and thinks all legacy code is bad, and they could do better. And I had some responses to it. I was like, you know, like, sometimes, sometimes the legacy code is bad, and they made bad decisions. And there’s maybe plenty of reasons for it. It’s justifiable, but but it was, it was a discussion about like, maybe some different perspectives on what legacy code is, and different ways to look at it. And I will confess that I, I’ve had a change of heart, in my opinions about legacy code. In general, I think I used to have a more negative opinion of it in general. But it was some good points made on that thread will have a link in the show notes. But some of the people called it, they said they don’t call it legacy, they call it revenue generating code, or they call legendary code. And someone else had a thing where they said that all the senior Amazon engineers have to have to really like take in this concept of respect what’s been done before. And I think that there’s all this talk about, like empathy and developers, you know, this year, and I think that having an understanding and a concept for why the legacy code exists. And and it’s not that the code existed because you weren’t on the project yet. It’s like, there’s reasons why it is the way it is. And if it’s making money, it’s not bad. If it works. It’s not bad.
This I you know, this idea of the way Amazon approaches, it is something that I think I’m you know, I have some empathy for because, like, we’ve got back in software for our company that goes back. I mean, honestly, 20 years, in some cases, yeah, not the whole platform. But parts of it, certainly, you know, at but some of the code only goes back six months, and then stuff that you can’t just come in and rip something out or anything like that, because you may break payroll, and then nobody gets paid. There’s, you know, there’s that you have to pay attention to what is there and why it was done. And it may not have been changed explicitly, because of that idea that its revenue generating. Its code that couldn’t be written better today. Yes. Does it need to be not necessarily, not at least not until maybe there is a, you know, a business reason to do it. That doesn’t mean it’s not, you know, old or whatever the case may be. I was thinking about this and, and a metaphor jumped in my mind. It’s a lot like cars. I like cars. Aaron and I were sitting here before the show started, and we were chatting I’ve got behind me, I’ve got a pile of brake parts for my triumph that I’m working on. Its massive. It’s Yeah, there’s a lot of parts.
Don’t Don’t be back too far. Yeah.
Yeah, we are the clatter and as great shoes and brake drums fall on my toes. But the idea that let’s say a try five. Chevy, if you’ve got an old, beautiful Chevy BelAir, that is a legendary car. It was isn’t how we would build a car today. You’re not particularly adaptable, like, if you’re gonna, if you want to pull out that old blue flame to 35 out of it and put it in a modern motor and transmission, you don’t just take it out and do that, you have to make modifications, you have to make changes, you have to make adjustments for you know, everything, if you’re going to put in, you know, 700, our transmission and a small block 350 or something in there and LS one, you don’t just leave the old differential in there, you’re gonna have to take that out. Because by putting in a better motor and transmission, you’re going to destroy the the differential. So you have to put in Yeah, that a rear in. So it’s like, it’s that idea makes a lot of sense to me from that it’s like it. I like that mean, anything is wrong with that car, it just means that it’s an old car that is revered. And it still makes money today, getting bought and sold and doing it. But too upset it to make one of those hot rods that you see on you know, Macomb or Barrett Jackson, or some of these, you know, there’s there is debt to be paid to get there. And that’s why these cars costs 70 $80,000 when they’re done.
You know, it’s even if you wanted to do something really simple, like so I like your analogy, because it’s the idea that it’s all fine. And it’s, you know, it’s perfectly serviceable until you want to add something to it, like you want to add perhaps a CD player to conditioning. So if you want to. But even just adding like a car stereo, we have a standard slot size more or less, or at least we did like in the 90s and 2000s. It’s getting weird now because every car is a different console. But you know, if you could just swap one head unit in for a different one. And most the time, it would just work. But an old like my dad is to restore cars. And so I like the slot in the inside of the console is often in like a weird shape. So you can’t just pop it in, you have to change things. And and I think that that sort of works with like, when you have a legacy code base, it may be working, it may run just fine. But if you if the client or the user wants to add new features to it, okay, well, maybe you have to make some changes.
It does, it means that or it doesn’t mean that any of those were bad or wrong decisions like that. And the way you know, when people look at technical debt or try to address it, one of the easy things traps to fall into is this idea that you’re trying to fix something that was wrong or dumb. And that’s just not true. It’s just changed over time. And I mean, it doesn’t mean it wasn’t dumb. You know, there have been very stupid cars built over the years. But that doesn’t mean that’s the sole motivating need behind that kind of change.
There. There’s a hubris in newer develop, that reminds me of the Dunning Kruger effect, you know, the one with the curve, where the less you know about something, the more confident you are, in what you know, offensively. I think that newer developers will get to a point where everything that they didn’t write, or everything that isn’t written currently is bad. And or it was like, written by dummies or whatever. And I fully admit, that was me at one point. And, you know, I, yeah, I have had that. Maybe not they were dummies, but I’ve certainly felt like, like, oh, obviously, I should, like, update this and rewrite it to make it different. And occasionally, I still fight with that a little bit, because I want code to be the best it possibly can. And sometimes it’s really hard, especially when you’re dealing with the friction. Yeah.
Because in and anticipating, you know, because I think once you get to a certain level of technique and experience, you start to treat technical debt with the reverence that I think it deserves. And so you as you build, yeah, then you think about it in terms of not, how is it going to be thou, it’s how am I going to take care of this, when somebody sends me an issue three years from now, and you write, you try to kind of slow some of that down and make those very deliberate decisions. And even leave space, I think, is kind of the way I approach it. Sometimes when I know something can or may change, I try to make sure because what like we use a model, that is a and this kind of goes to this idea of the to do comments from earlier, we have what we call the one two in model, the first two times were asked to change something, we’ll just make a change straight up, basically, yeah, we don’t worry about doing the extra work to make it dynamic or changeable, until we hit that in. So after, after three times, we’ve now entered a state where there is a clear need for something to make it easier to change more frequently, so that we don’t have to go in and do that every time. And that’s where we add that in. I’ve heard of that before. It’s just kind of a, it’s a technique to kind of make sure because there’s this other phrase, because every everybody’s got, you know, cliches maximize the work not done, you know, not going to go balls to the wall and make this crazy, dynamic, flexible piece of code that takes a month to build and then write 2% of the power of it as ever used.
That that’s the the agony thing, right? You aren’t cutting yet.
Yeah. And so that, that helps us kind of account for that and adapt to it. And it makes debt kind of it almost makes that that that discussion, part of our strategy a little bit at that point.
two to two things, or I guess this one bigger thing. But the one of the things that’s changed my perspective on this a little bit is is understanding why decisions were made when they were. And sometimes, if especially if you’re on a younger product, if there was a lot of rapid iteration early on, when like a like a startup, for example, a startup may have a bunch of founder code or may have just other other code that was written in the early years of the app. And if it does, they weren’t trying to write bad code, they were just trying to rapidly iterate, and they didn’t have the time to slow down and do risk factors, or to maybe like, revisit and remodel things. I mean, that’s like having the time to do that is kind of a luxury. And if you’re in a really hyper competitive environment, you may not have that as a result.
Again, time is money. And if you are sorry, I was doing a startup. There’s something. So tonight, actually, and for those of you who wonder about my commitment to the podcast, this is my 10th anniversary. Tonight,
we just to be clear, we had a discussion before the show, and I gave him multiple chances to back out. So like I’m not making I know.
I know how to deal with that. Now. So my wife and I met the year Google bought YouTube. Whoa, about YouTube in 2006. YouTube launched in 2005. It took a year for them to launch a product, raise over $8 million in VC, and then sell to Google for over a billion dollars. Do you think their code crazy that point was the code that you wanted it to be? Because there’s
I’m 100% sure it’s in nothing,
Nothing’s more certainly. But that that cycle, and YouTube is a crazy fringe example. But it’s still true even at a small startup that you have to burn hot and bright and fast.
Because Yeah, you don’t
ship that product, within a certain timeframe, that money evaporates, and then you’re just stuck. And then you’re stuck with real debt. And that need that there’s that business component that will always come back to development that it sucks when you’re told to push something that isn’t necessarily ready because of a timeline. Yeah. But learning how to deal with that is just part of being a developer and and understanding that, why that happens, can help you avoid it and help you deal with it, but that that rapid iteration idea and that need to refactor code comes in part from some of that?
Yeah. Oh, there’s there’s one other point about this is was reminded today of a quote by Sandy Betts. She’s an amazing speaker and developer. It’s just training for software engineers now and she’s awesome. However, a couple of the reverse talks will be in the show notes. Definitely watch them. But anyways, she has this quote that she says and couple times, you are never going to know less about your requirements than you do right now. So making decisions about abstractions and larger engineering decisions, you don’t want to make it until you absolutely have to. Because anytime before that, you your chances are you don’t know as much as you will know later.
At best, you’re making an educated guess about acquiring Yeah, I like to think about it too, from the aspect of, you know, when it comes to growth, and iteration and change over time, imagine you were using html5 these days, you know, we’ve got fancy new tags and all this that we can use. I remember writing HTML with all capital letters back in, like, HTML to HTML 3.2 days, with, with the tags with all you know, all the frames that ugliness and, you know, we made decisions back then. And we didn’t things like layout a website with tables. Why? Remember that Dibs didn’t exist, or quite as CSS CSS? Certainly not. It wasn’t widespread. Yeah, CSS came out much earlier than people think I for I’d have to go back and look at it was late 90s, 9899, when CSS launched. Yeah. But that doesn’t mean like the stuff we wrote, back in 1996, 9798 was bad code. In fact, a lot of it was cutting edge bleeding code, the way we solved problems was revolutionary in some cases. Okay, wait, here’s, here’s a cool throwback for all of your younger listeners. So when you wanted to have text,
maybe you have a big block, right, and you would have text pushed down, say, 30 pixels from the top. The way we did it back then, was to have the text inside of a block level element inside of the parent block. And then immediately before the text, you use a one pixel transparent GIF, called spacer.gov. And you set the height of that as this height property to be 30 pounds.
There were a lot of novel solutions. No, it was it was us testing the system, basically. And would we do that that way today? Absolutely not. But that doesn’t make the decisions we made wrong or stupid or dumb. They were innovative. They were daring. They were challenging. And the same way that we look at that. Now. If I look at things like jQuery, I’m yeah, I’ve been making a hard push in our development cycles to eliminate jQuery from our vernacular, I want vanilla JS across the board now, because the reasons that jQuery existed, no longer true for the most part, jQuery simplified and streamlined and unified and experienced across browsers that were inconsistent. But a lot of those in consistencies don’t exist anymore.
It also made Ajax
it made Ajax ways easier. But now there’s no reason you can’t do that on your own. Or make your own make a quick function there. There are poly films and stuff, you can just include on it on it. So yeah, and have that if you needed to, that’s all vanilla js. And so I think of jQuery very much like that, like you’re going to see jQuery and code for years to come. But there is going to be a point where folks are going to start looking at that and being like, why, why do this in TypeScript? Right, you know, like that, it’s going to be that kind of thinking. And it’s not because jQuery was the wrong choice. It was the right choice. And those people writing that code, or those folks were still learning JavaScript, because jQuery does make JavaScript easier for new people. Yep, good. thing. So that’s, I like that word. hubris don’t fall into that hubris.
So from this idea of technical debt, with legacy with legacy code bases, I found this thing hold at ours. And now I forget where I found out about Oh, it was from that thread from that Twitter thread from earlier. So ADR is an architectural design record. Yeah. Or architectural decision record. Yeah. decision. Yeah. And so what this is, is is kind of a cross like a written chronicle of the discussions and decisions that were made about the application and why. So that in the future, you could go back and look, and have some kind of frame of reference. It’s not like in comments, per se. It’s like a separate document. And there’s a there’s a GitHub page. Yeah, ADR GitHub, that I Oh,
yeah. And and there’s a repo by this guy, Joe Henderson has got will have both of these links in the show notes that they’ve got a ton of resources from examples, you know, structure for these documents. And how to apply them. I because this was the first I hadn’t heard of it to when when Sarah and had found this, and so I got to looking at it. And I I immediately latched on to it. Because like I said earlier, the reason I think code commenting is important. That process of communication and documentation, I think is important and valuable. And this gives some structure to that. Because documentation, let’s face it, it’s really time consuming. There’s a lot of documentation that you’re going to write in your life that will never be looked at by another human ever again. But probably that exercise, I think, is really important. Because when we get back to these things, why did I choose to use jQuery on this project? Well, I needed a framework to help me with animations and streamline my Ajax calls. These things can then be documented so that if you aren’t the person maintaining it in the future, and they get in there, they can pull that up and see, oh, here’s the reasoning. Those reasons have now changed. So we can maybe, you know, do something else. Yeah, that’s, I think, one of the big values there. Because here’s, here’s the thing about technical debt. There isn’t a single point in time where you look at code and you’re like, yep, this code needs refactor this idea of debt code rot these ideas, I think about like a frog in boiling water, where it’s such a slow burn kind of change to code over time, that at some point, you just know that your past do and then you want to do something about it. And then you need to know why. And and what is what is it going to affect? What were those processes that led to that?
There’s the sorties paradox of moving i think i saying the name right, moving, moving additional grains of sand into a pile? At what point? At what point? does it become a pile or a heap? Or something larger? If you if you just move one grain at a time?
Yeah, it’s it’s a hard question to answer, and there really isn’t a good answer. But this can help you in that process, at least because you can be like, I’m going to change as you pump the ATR. You look at it and see Oh, well, that they had to do it this way, because of an infrastructure decision that was made prior to that, even if I change it, it’s going to impact this other stuff. So I’m gonna, I’ll wait. Because we lack that a lot as developers,
I want to make sure I mentioned although Joel Parker Henderson has that most current GitHub repo, I believe he references the original author of this concept, which was Michael it’s either Nygaard or Nygaard, NY, GA rd, who seems to be the person who kind of
Pioneer originally made that
Yeah, like sort of came up with this idea of doing an ADR. That’s sort of like the history of it. But it seems like the this other repo is the one that’s maybe more actively carrying the torch on that.
I like the idea of just making this part of your process too. Because if you’re already using like a get repo or something like that, or if you got Confluence, or some other wiki or something like that to document your stuff, then this is just a matter of putting together some mark down and including it as part of the completion criteria for work that you’re doing for the project. And it’s worth mentioning, like an ADR is not geared towards a ticket. Like it’s not geared towards work. It’s geared toward right? architecture, and the decisions that go into that,
this evening. It’s things like we chose to use this database, or this platform or this framework, because of these reasons. And then just saying why, and that way, when maybe the original team is gone, or moved on to different parts of the organization. Newer people can look back on that, and then can answer the questions like why the hell did he like
if you’ve ever looked at a database and seen a column for date, but but it’s being stored as a string instead of a right instead of a date? It’s like, okay, but there may be a good reason for that, that you aren’t privy to. And, again, that idea of I’m just going to change that I can make that better. I’ll recap.
structure. And then you realize, again, you broke payroll? You know, it’s, that’s, that’s a great example of why comments might be necessary. If you had, if you had to add something that was like, well, we have to treat the data as a string, then parse it in this way. Because start that way, the table like the the approach you’re taking to it, there might be a super easy approach to use it as like a date time object, but you just can’t do it. Yeah.
Or, you know, if you’re sitting at a table with folks, and and you’re using my sequel, and you’ve been using MySQL for 15 years, and everybody’s like, you know, we could do this a whole lot better if we moved over to like Oracle, or ms sequel, Postgres. No, nobody ever says those words. But it maybe they would, and you’re like, yeah, we we didn’t do that, because we couldn’t afford it. And so you’ve got record that says, Yeah, we we went to my sequel, because we understand that there are limitations to it, but it was free. And that was most cost effective. Or, you know, post grace. Yes, that is another option.
And to be fair, that is a completely valid reason.
Totally. Oh, yeah, absolutely.
Yeah. Like, it’s, it’s this isn’t, it’s not like a blame game or anything. It’s just, it is what it is, and just
have to accept. Remember when I said earlier that you know, like code comments, use code comments to answer the why sometimes, yeah, code code can’t answer the why it is incapable of why it is only capable of what, at ours help answer all of it, they can answer the Yeah, they can answer the what the win is an important part of that the Y is an important part of that. So having that that decision record, as part of your documentation helps you understand all of that big picture, because ultimately, that if you are working at a company, or you’re working for yourself, whatever code you’re riding is going to have business decisions driving it. Yeah, revenue generating code. And so the business logic is something that can change at a company much more quickly than code can. And you may run into code that doesn’t make sense. And you don’t know why. And it may be perfectly valid to change it, because you’re looking at it and like, we don’t work this way anymore. Why would you know, why would we be logging time in these increments when we have real time, you know, a time clock in our tracking system. And yeah, pull that. And you see, that lets you justify, then when you go in and say, Hey, we found this code. Back in 2004, this stuff was built out this way, because of this. We’ve gotten rid of those, we would like to change this now. Because we’re worried that it may introduce a bug later. Like, that’s an important decision making process. But without the design record behind it. You’re guessing. And I,
I may have mentioned this already, but I’m having an ADR is it’s a process. It’s not like a product. Yeah, this is you don’t you don’t get the ADR software and then do stuff in it. You can use anything, you can use Notepad, you can use, wiki, you can use, you mentioned Confluence, you can use whatever you want to use for collecting things. I think the only the only requirement is that you’d be able to easily edit it, and maybe having like, different pages would probably be helpful. Yeah, totally. And the ability to maybe a link across them would probably also be good. And maybe something attracts, like the version history or authorship would also be good. Um, but like, you know, it’s it’s really software agnostic, or even the mean, medium agnostic, you can do it on a notepad if you want, like a physical one that
you could physically have a notebook on. Your team refers to, right? It’s just about documenting information and decision making. Just something that isn’t we don’t teach Well, we don’t explain well, but has, I think, obvious value in a business setting. Because it does protect like a and I give credit to the folks I work with, because they are some of the smartest developers I’ve ever had the pleasure of working with. There are times where we can run into code where it’s like, ooh, we don’t do this anymore. Can we get rid of it? or Why? You know, that or the debate that just happened? The The funny thing that factors into this, is we’re getting ready to build a new tool. And the question we asked was, do we do react? Or do we do Angular? could do it one way or the other. And we don’t have like a real horse in the race as to which one, they both will do the job. So which one do we pick? And we you know, had conversations everything. And the thing is, like, we’ve already invested as a team in Angular outside of my like, my particular team, but you know, there’s that decision making process that we don’t have documented. So I had to just keep asking the question to find it out. And those things in those environments can make it challenging, because then somebody may go and make, you know, just be like, I’m going to, I’m going to bringing Ruby, and I’m going to do this project in Ruby. And everybody does like we avoid Ruby, because we can’t run X, Y or Z, you know? Yeah, I mean, I know, that’s a silly kind of example. But decisions get made and helping, especially new developers, when you bring in these new developers, and you can say, okay, you’re coming into a system, the system has existed for 10 years, and was here before you and it’s going to be here after you. And before we let you loose in our code base, you need to read some of this stuff to understand cuz we know you’re going to look at this stuff and be like, Well, why are you still using info basic over here and cobalt over here? There are reasons. They are great reasons, but they aren’t good enough to change at this point. So here’s the stuff that explains that.
You could you could even use just an audio recording. Like if you have meetings, remaking, you know, like, you’ll sit down and make decisions about design, you could just put a recorder in the room and record those. And then you always have something on hand. For those decisions. I just I think it’s about an archive about a stuff like documenting your process.
So that that helps the historical side of technical debt at ours are a preventative measure, right? They help explain and help you understand and help you safeguard for change. Sure, but then how because you do deal with that you have to address it at some point. So where do we start on what’s like the best starting point for something like that?
Okay, so this is the stuff that I’ve been like, really learning about in earnest last six months ish. It’s a refactoring and get into the definitions in a minute. But like, I think there’s a quote that Martin Fowler, who wrote the book literally wrote the book refactoring, I have it right here. I have the refactoring second edition, by Martin Fowler. I also have the refactoring Ruby edition, which uses Ruby This one uses JavaScript, just like vanilla JavaScript. The first edition used I believe, john,
did that have like a built in but mark two? Did I see a
it does, it’s a really nice, like, it’s a really nice, nicely, nice high quality book. it for real, I like I’m very happy with this. But there’s a quote by Kent Beck, which is a make the change easy. Sometimes this is hard, and then make the easy change. It might be a slight paraphrase there. But but that’s kind of the basis of what refactoring is. And they say,
explain it to me simpler.
Okay, so say that you have a drop down list of states. But sometimes it’s also like regions, right? Okay. on your on your app, and then they want to add, they want to change it, somehow, they want to make it a you know, map to zip code or whatever, hey, so like, or they want to add a new region or want to add a new state, there might be friction that you encounter when trying to add that feature. And so what he’s saying is, the first thing you do is you you change the existing code, you leave the behavior as as you change the existing code implementation, so that adding new things becomes easier. So you’re you’re at the point where you are aware enough of the requirements of the direction this code has to go, that you can kind of revisit or revision, how, how it’s written. And then once you’ve done that, because sometimes it can be challenging, then you’ve now made the change easier to make. And tonight’s make the thing you wanted to do originally,
okay. Okay, so this sounds kind of like the one to in thing I was talking about a little bit? Yes. Let me Yeah, I think I have an example of this. And let me see if the way I do this. Sweet. Okay, definition. So what I do, if I run into old code, what I have a habit of doing is especially like when it’s embedded in something, I will pull all of that old code old code out. And I put it in a file. And I would add a code comment into that file that says, you know, this was extracted from such and such, it was moved out because of these problems, or whatever, I can’t take it out, because like you were saying, it’s sometimes not in scope to spend five extra hours totally rewriting something that’s unrelated to the work you’re doing.
Right, what I’ll do is I
abstract it out. Then in the gift code, I just put a pointer to it. I reference just the one thing Yeah, I’ll parse in that file. And then I’ll have another code comment that will say, Yeah, something to the effect of, Hey, this is what we’re doing. This is why this is abstracted out. And then I’ll make tickets or whatever the case may be. But I try to simplify my life by taking everything old, and getting it out of my way. It’s still, so what you used, but it’s just a level sort of way, kind of
what what you described there sounds like the code smell gets done in a second, either large class or long function. And one of the remedies or refactoring techniques for those is extract class or extract function. So like, what you described is one of the techniques and so on.
So I have done the book, I don’t need to read it.
You’re an expert. I don’t know why I’m even talking about this. You already know. Awesome show so far. Unknown Speaker We win. Okay,
that makes sense, though. I like that.
So, so Martin flower to find he so I definition here refactoring is different than restructuring. So like, I’ve used the term refactoring in the past, very generally, just to mean like, Oh, I’m just changing how my code is, I’m improving it. And it’s not it’s that’s not the same thing. That would be what he might call restructuring.
So as described as that a restructure, because I moved it.
Well, no, but you actually you, you kept the behavior the same, right? You just changed how it was written in turn. Yes. So that’s, that’s a real factor. Okay. Yes, that’s, that’s actually I’m glad you mentioned that that’s a one of the key differentiators and refactoring is that when you’re changing your kind of like, you’re going into the car, and you’re like, you’re maybe putting a new engine in, or, I don’t know, changing the seats out or whatever. But they still function as seats where this the engine still makes the car move forwards when you push the gas pedal, or the only difference is is how it works. I think a good example,
there’s like batteries. old old cars were six volt. And so what people did was to get them to 12 volt, they put in 12 volt batteries, and then put a giant fucking resistor in line. Six volt, for everything else. Yeah, but then, yeah, change. They’ve abstracted away the battery voltage, so to speak, and they’ve got a little thing that just takes care of that translation. So that they don’t have to change anything else.
Exactly. That is that’s a great example.
Yeah, man, I’m on it. I got this.
You are car analogies work for everything, apparently. Oh, so the other thing the other part of refactoring to it’s, it’s, it’s the changing the implementation and not the behavior. And also, there’s this idea of code smells. And these are like objective things that have names and descriptions. And it describes very specific things that each code smell has common refactoring remedies that you can apply to, which also have names and I have a couple
household, I’m told that I’ll just smell frequently. So I like that kind of smell that gets in your mouth. And you can’t really get it out right
away. Like you can like, you can almost like
eat Yeah, yeah. Like, like chew on it. It’s good to chew.
So the code smells from the back of the book here. They’re like data clumps, duplicated code, feature envy, insider trading, lazy element, long parameter lyst middleman, mysterious name, shotgun surgery, that’s a fun shotgun surgery is when you’re making an edit. And you have to make the same change and a whole bunch of different places in your application.
Hmm. Find and Replace.
Yeah, exactly. If you have to do Find and Replace on the same string and replacing it with the same other thing. And it’s not just like renaming a method, or maybe it is just renaming the method. But it’s when you’re having to change the same thing in a bunch of places. That’s chocolates,
or how many of these are there?
Two, three, I’d say probably about 25. So
yeah, so there’s like a lot, then.
Yeah, yeah, your show you that. There’s like, kind of grouped into rows, I’m showing Michael on the webcam. So each of these, for example, feature envy, the remedies or refactoring techniques to fix that. They suggest either move function or extract function. So like the process of learning to do this is you you first learn how to identify the code smells. And then once you’ve identified which codes know you’re looking at, you look up at the table, and you say, like, okay, these are the techniques that I would use to resolve that. And so the chapter one, in the book he goes through, or maybe chapter two, it’s very early, though, he refactored is like a kind of a micro app, just like a small section of an application. And, and the, the process that he goes through is he looks at it as one code smell. And then this is all done with a passing test suite. So he has a green test suite that tests the important behaviors. And then he identifies the code smell, he applies, the remedy confirms that the test still pass, and then like, commits this change. And now he does the same thing again, find a new code smell, apply the remedy, make sure the test pass, commit the change, and so on. It’s just this thing intuitively, at any given point, you can stop and your app is still stable. So you don’t have to fully refactor something, you don’t have to take it all the way you can do it just enough so that you can apply your change to it.
It does. And this emphasizes the importance of why testing is,
yeah, tests are absolutely critical. absolutely critical to this. There’s a if your thing, if whatever language using doesn’t have automated testing built in, there is an approach called I forget what it’s called. But basically, it’s a thing where you treat your program like a black box, given this input, if I give the program to it spits out fine. Yeah,
to me, and that that’s test driven development.
Sort of, but you’re not writing automated testing, you’re just writing a thing that just runs your program with a very specific input and a very specific output. And that’s all it’s looking for. So it just basically just sort of a smoke test to make sure that you’re not breaking your program in between your changes, you keeping the behavior the same. Um, the other thing he talks about in this, too, is changing hats. So he has his refactoring hat. And then he has his like development hat. And so the refactoring hat when he’s doing that, he only changes existing code implementation, he doesn’t change behavior. And when he’s wearing his other hat, he will only change behavior, he won’t change implementation. I imagine that’s kind of maybe an advanced program or technique to just know when you’re wearing which hat and keep your activities to only doing one or the other. But that’s kind of what what he advises is the best way to approach this, you
know, what I like about this idea of like, code smell as I like the name, right? It’s because it has like a an analogue to what I feel like I do when I see bad code in practice, like, yeah, it has some kind of relationship. That phrase we used earlier, like code rock. Yeah, yeah, code starts to rise, it will develop a certain smell. And one of those smells will be in that book, I was really surprised because I think as a developer, you will develop these techniques. I think we all kind of do this. And we see code, we know when codes bad, or we know when something isn’t as optimal as it could be, as we’ve got Yeah, gotten more experience or learn more. But I never stopped to think about like, compartmentalizing those concepts into discrete types. And the idea there Yeah, it’s five of them is kind of surprising. It’s,
it’s a really formalized process. And, and it’s really cool. There’s some great talks that I’ll be put in the show notes, where you can watch someone I swear, this is more interesting and exciting than it sounds like when I’m describe it, but you watch someone like Sandy mats, or one of these other people do a refactoring live, like, you know, she’s going through and she’s like, Okay, well, this is why this is what I would see here. And this is what we’re going to do, we’re going to move this over here, then we’re going to change this and and she’s running like, you know, analytics against that the whole time to like, kind of see how it’s the complexity is changing over time. And then the end result is completely different looking in the beginning, but it runs the staff. And it’s it’s just it’s so fascinating. And it’s just, it’s just beautiful. There’s something
satisfying about watching somebody condense 50 lines of code down to 20. You know, yeah, yeah. And I’m going back to earlier and talking about this idea of code commenting and things. You know, one of the things I see where commenting comes in handy is explaining advanced developer techniques that are in practice. And one of the examples that I’ve thought about is like JavaScript, short circuiting. If you’re not familiar with JavaScript short, yeah, it’s this idea of taking a conditional like an if statement. Instead of having if this curly bracket, do these things in curly bracket, whatever, all you do is say something like, is valid. And and function name. And that’s it. You condense, you know, eight lines down to one. And yeah, I remember the day I learned about JavaScript, short circuiting, because I was trying to do a, a template literal, in a file and some j sx. I didn’t know about short circuiting. I didn’t know that was the thing I just hadn’t ever ran into it. I never learned it, because I’m, I’m one of those folks. I’m learning some of this advanced JavaScript, having done old JavaScript for a long time. And so one of my other co workers was like, why don’t you just short circuit it? And I said, because I don’t want to move this box up. I don’t know why I would try to ground something that shouldn’t be grounded. That doesn’t make sense. He says, No, just write it this way. And I looked at it, I’m like, why would I write it that way? That doesn’t even make sense.
It was the articles you shared, had the example like, where instead of saying, if this if name? If like name is set, then do this thing to name make the name uppercase. Otherwise, do something. Yeah, right. That was the thing. And so it would be like name and and name uppercase.
This comes in like, you know, there’s a lot of shorthand technique that’s out there for different things that people don’t learn about that. Or even CSS take CSS. You know, there’s a lot of shorthand technique for things like background. You don’t you don’t have to say, Oh, yeah, background image, background path, background clip background position, you can smash all of those together into one background statement. Yeah. It’s hard to understand that stuff without comments and things like that. But you can, but if you when you watch somebody who has advanced, go into code and look at stuff like that, and be like, Oh, yeah, we’re going to take all this stuff that you’ve done line by line, and like you’ve enumerated a lot of stuff. And it’s like you get it enumerating It is useful and good. And it helps you learn it, especially when you are getting into that stuff. But once you get into, you know, advanced developer lands like you, let’s just let’s shorthand that let’s smash it all together. It’s wild to watch people do that.
I saw the first time I saw a SAS document and it had like a huge sum of my comments and the almost like a directory of everything that was in that like sash suite. I was like, oh, man, I like it’s I’m so glad that ahead. But so, comments is one of the code smells. Yeah, here’s what, here’s what Martin Fowler has the set of and I really liked how he writes this here. He says, Don’t worry, we aren’t saying that people shouldn’t write comments. In our olfactory analogy, comments aren’t a bad smell. Indeed, there is sweet smell. The reason we mentioned comments here is that comments are often used as a deodorant. It’s surprising how often you look at thickly commented code, and notice that the comments are there because the code is bad. And he goes on further about what you might do with that. But I like how he says that, because it’s
that’s you know, you know, not just fair, but I mean, it does. It gets to I think what, Brian Orlando with his article, and what he was getting at, effectively, and I do I I’m a big fan of metaphors. I’m like a shark. And I think that one does it
works for me. Like if you don’t if you don’t use a metaphor. Well,
yes, exactly know what we all because I get up every morning when I get up in the morning and I put on deodorant, I don’t stink, I smell good. I just get out of the shower. I’m, I’m done. I’m preparing for the day. But that’s the thing. The putting on the deodorant is your preparation for the day. And right and yeah, it gets you through. And by the end of the day, if you’ve gone outside, and you’ve worked and you’ve sweated, if it’s doing its job, it’s still going to help cover that up. But it’s not going to change the fact that if somebody looked at you, they know you’re hot. And if you look at old code, or bad code or code that just has rotted a little bit over time, and you see that I get it, I can read the comments, I see what’s happening. But I can tell that it’s using the technique that we can do better at now.
There’s two, Brian Norlander his credit he did quote, Martin flower, specifically, this book that I’m holding in my hand in his article, and the quote that he used was, when you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous. And a couple of examples he gave were like To that end. While you were saying earlier, like the spirit of most of his article, I think I agree with but just not the clickbait title. So
So what can what can we do with this information now that we have it though, like there is, okay, there’s, we have these things, we have ideas, we have code smells, we have this understanding of it can be bad code, it can be old code, it can be many things that need changed.
So there’s a talk in the show notes by Sandy meds called Get a whiff of this, and it’s specifically about code smell. And she talks about like, you know, the, the different names and she focuses in on like a small set, maybe like 10 of them. And she shows some examples on how to deal with them. And then there’s another one called all the little things I actually we just watched that with my work today. Where she goes through the it’s called the gilded rose kata. And kata is kind of an appropriate of term. So I tend not to use it. But that’s the name of a kata
is like a technique.
A kata is a I mean, it’s borrowing from like martial arts, it’s like a practice,
it’s
Yes, it’s like a, it’s a drill that you can repeat over and over again and drill I like that chief perfection
word for a drill.
But like in martial arts, kata forum would be one like you, it’s not practical, like you wouldn’t formally do it. But it covers all the range of motions and movements that your body might need to do do when applying the underlying technique. And it can you can kind of meditate on the movement to get a deeper understanding for it. And I guess maybe some of these might, like, I kind of think that once you’ve done gilded rose, for example, if you’ve done it once, you probably are going to approach it the same way the next time. So I don’t think it’s necessarily repeatable. However, it’s good practice. It’s like a problem set, sort of like from a math textbook or physics or something. It’s a problem set that you can use to help learn these techniques, you can learn how to solve them better in real life in your
actual code base. So how does gold and Rose work then,
oh, it’s a you’re gonna have to watch the talk the sample she so she does it in Ruby. And Ruby is thankfully very easy to read. So if even if you don’t know, in your Ruby, it’ll still make
sure it is.
But it begins, I think it’s like a 20 or 30 line conditional statement, like if else if else, it’s just a huge block of it. And then the the resulting code that she comes up with is maybe like 15 miles or something total, it’s really short. But it’s, it’s a lot easier to read and ultimately modify at the end. But basically, the what the gilded roses, it’s, it’s a fake code base that was written by someone specifically for this purpose is a bunch of like weird turns, which I think are from World of Warcraft. It’s, it has all these different like item names. And each of them, they they tick, they they either increase or decrease in quality each time the tech method is called. And so there’s a whole bunch of I branch conditioners, the very beginning, that just covering all these things. And what you want to do is you’re supposed to add in a new item type to it. And as it stands, adding in the new item type, I guess you could do it just like the other ones are. But the idea is you want to do it better. So there’s there’s that there’s a if you look for, like refactoring practice, there’s some different like repositories and things that have it, basically, what it looks like is you get kind of a starter app that may that may have some automated tests, and then you kind of like, interactively, like improve it towards some goal, like there’s one that I found this like a babysitter thing where it’s they describe the the criteria for how the app is supposed to act. And then they decide they describe what you’re supposed to add to it. There’s another book, also by Sandy meds called 99 bottles, I want to say it’s nine bottles of object oriented programming. But the first chapter is it, it gives you there’s a repository you download, and then it has a series of automated tests that run sequentially. And each one of them, you start out with an empty prob, an empty class, and you have to just add just enough code to make the test pass. And then the approach that you take to it, there’s a couple different ways you can approach it. She does a talk where she kind of talks about different ways you can tackle this, but hop into the show, so it was kind of rambling now
No, no, there’s a In fact, I there’s an article over at lunar logic that will have a link to buy Arthur also, chop, I think I apologize again, names are not my strong suit at this point. But he went through the gilded rose kata. And yeah, he wrote up like his experiences with it and and where you found that to be helpful and things like that. I’ll have that in the show notes today as just kind of an explainer as one of those.
Oh, you did in Ruby?
Yeah. Yes, the same Ruby library, the same, like it used her code base. So it’s a good like, it’s a good sort of branch, branching topic. From there, what I like to do, and this is nowhere near as complicated or anything like that. But like, when I’m in GitHub, or we use JIRA, at work, we just have a label called tech debt. And so when we run into work that we know is going to need extra stuff later, we log that ticket, like we were saying earlier, you make the ticket, that’s step one in fixing code. And we label it tech debt so that we know that like, this isn’t work that we need to do, because it will make it functionally better necessarily, but it’s work we need to do. Because if we’re going to ever expand on it, or add to it or to other things, we need to make it better first. And then we can when we do sprint planning, we can sit there and say, Okay, do we have time this week to bring up some tech debt. And we’ll try to spend you know, if if one developer can spend an hour that week, fixing the tech tech that that that I switched earlier, I didn’t say it but I switched over to the Bri from hi was distiller. If somebody can take on one of those tech debt tickets, then you know, that’s all you can do, it’s just like paying down the debt, you just have to make a regular payment to it doesn’t have to be a lot. If you only ever make minimum payments, you’re probably not going to get real far, but at least it’s not getting bigger.
I think that there is a lot of value to be gained in prioritizing. Even just a small percentage, like if he just said, one day a week, or even like half day of the week or something is allocated for the whole team, or just certain people or some number of people to put towards working on technical issues. I, you know, it doesn’t, you don’t have to solve all the problems, but you should make it a habit of solving some of them. Or just do like one day a month, you know, like, it’s like 5% of your time.
That’s where like we’ve talked about, you know, let’s find a sprint, where like, it’s like in our low periods, so to speak. And let’s take that sprint and just scheduled technical debt and see how much of what we can get done. Let’s all focus on that. One spray? Yes, not that much. You know, we our sprints are a week long, so we got 52 of them. And so we said, Yeah, just one week, 40 hours per person is going to be spent towards it’s like, it’s like spring cleaning. It’s, it’s a cleaning, yes, keeping those tickets out of your backlog. Because it is it’s a rock thing. And if you if that epic that you’ve got starts to loading up with technical debt tickets, at some point, you’re gonna look at that, and you’re like, crap, we’ve got 200 tickets in here, guys. That’s a good sign. And it starts coming up in conversations you do sprint planning the next week, and it’s like, oh, yeah, we’re gonna we need them add these things to, you know, a landing page generator to an email system. And you’re like, Oh, yeah, but we can’t do that, because we haven’t addressed this. And the more of those you have, the more that smell starts factoring in to those discussions, and you’ll notice it, you will start to notice the smell.
The advantage of the refactoring process in that book is that if you are only able to intermittently do it like that, like if you only have one week out of the year, that you can devote towards technical debt, you don’t want to get to Friday and have code that’s like only three quarters done that you can’t commit yet, because then the whole week is lost, right? So with refactoring, like every iteration, and they’re like, very small iterations, each remedy, you apply results in a stable application. So you can, you can really do that and just make, you know, one week of changes to it that improve stuff, and you end up with a stronger app, because of it,
we also use this methodology of leave it better than you found it. And that doesn’t mean refactor tons of code or anything like that. It just means that when you’re in code, even if it’s one line, you know, like, and this is one where I run into stuff where it’s like variables, right, you see a variable set, and that variable got set, because you were using it in 12 different places. But over time, you reduce the usage of that variable. And at some point, you realize, you look at a file you’d like we’re setting a variable, and it’s never getting used. Now,
I have a habit of doing that with very short renamed variables, like if it’s maybe like it’s referring to temperature, but they use the letter T to represent temperature, I’ll just replace if it’s just all like in a small little five line block or something. I’ll just replace it with a longer named
variable, I’d help them if they named it temp. Right, exactly. I think that’s actually a code that’s actually a technique name is in our code base of using like, underscore, Tim, at that things that end up putting out No, that’s a whole other story. But it’s like doing something like that, once you realize that just delete, it doesn’t matter if thats related to the work you’re doing. Delete that one line, and you have now left her code better than you found it. And there are a lot of easy ways. He doesn’t mean you have to rewrite 30 lines of code. But there are a lot of times you can look at something and just notice, oh, man, we could swap a couple of these things out real fast. And I’ll just leave that better. And then when you do your code, commit and put in your review, just leave a comment that says, I left this better than I found it. And you’re if it’s been commented well and is written well, then it should be obvious why you did that. What I think that emphasizes is what we say a lot in web development, which is that technical resolving technical debt is not a goal. There is Yeah, finish line to it. Now. It’s it’s a process.
Yeah, code, your code is going to constantly write
any code you write today is worse than the code you will write five years from now. It just is.
Well, that’s like saying before, like, you know that you know the least about your requirements now than ever.
Right? And you absolutely, yeah, libraries change techniques, change technology changes JavaScript. You know, what’s funny about JavaScript is the reason why that has come up so much in these conversations is JavaScript used to never change and that was the problem. Now we get a release every year. Yeah, we didn’t do that before 2015. Before 2015 JavaScript released, but it wanted to every few years, now we get a release every year. And it’s really changed the way people think about JavaScript. That process and the way we approach it, it’s a it is a cycle, it’s a maintenance cycle. And it’s just something to kind of keep in mind and and you want to keep your debt to a minimum, but you’re always going to be carrying some of it over there’s no way around that and and success is measured by growth and shrinkage of that ratio, is maybe the way to think about it.
And I think instilling in part of your team culture, you know, like that, that you’re just going to you’re making intent to constantly be paying down some of it over time, I think I really think that there’s multiplicative benefits from it. Because as you’re replacing painful things, you’re going to be able to iterate faster, because you’re gonna have less friction to make changes. So there’s, it’s not just about making it look prettier cleaning up or whatever, like, there are tangible benefits.
And if you sit down in your sprint planning, or whatever planning you happen to do for your process, even if you’re just yourself, if all you are concerned with is always building new stuff, and never reviewing old stuff. That’s the first sign that you are setting yourself up for a future problem. There should always be that process of even casual review, just read look at something, make sure it’s still the best way to do it, make sure you still feel good about the code you’re writing, can it be more performant can use a faster library can do something else, that that cycle is something that we all have to get used to and understand that if you find debt, that is not a sign of any kind of failure.
Right? Yeah, it’s a, it’s sometimes if you see that you may be able to look at it and consider like, what do I know now that I didn’t know then that I can change? Right?
One of the whole hardest things to do as a developer, I think, is to look at code you wrote five years ago. And be okay with understanding that Oh, yeah, I, man, I would not write that that way now. And if you can, once you get to that point, that’s where I think you’ve really kind of matured as a professional, where you can say, Oh, yeah, man, let’s make sure we deal with that. Because, boy, I didn’t know these things that but
that’s okay. I think you should, you should, if you see that you should frame it to yourself as like, look at this. I wrote crappy code, and it’s still worked.
If nothing else, it is a sign of how far you have progressed. Because if you ever look back at your code, and you never say that to yourself, yeah, that means that you aren’t getting better. And that’s a problem. That’s the thing you should be worried about. Looking back at old code. If you look back at a code you wrote a year ago, and it terrifies you. That’s great. Because that means you have really learned a lot in that year. And that’s a good sign. In other words, you should always think
is tell my when I was ta for Oh, come on. I was always tell my students to like, I want you guys to ask questions and be wrong as much as possible. Because it means that you’re learning. You don’t you don’t learn if you’re never wrong, unless you’re asking the same question over and over. Well, I suppose.
Books, kick back. Wait just a minute. We’ll be back here. And I don’t know. What else things, notes, things, cool things. cool things. The drunken UX podcast is brought to you by our friends at New cloud. New cloud is an industry leading interactive map provider who has been building location based solutions for organizations for a decade. Are you trying defined a simple solutions provide your users with an interactive map of your school city or business? Well, new clouds interactive map platform gives you the power to make and edit a custom interactive map in just two minutes. They have a team of professional cartographers who specialize in map illustrations of many different styles, and are ready to design and artistic rendering to fit your exact needs. One map serves all of your users devices with responsive maps that are designed to scale and blend in seamlessly with your existing website. To request a demonstration, or to view their portfolio, visit them online at New cloud.com slash drunken UX that’s in you cloud.com slash drunken UX. Everybody, thanks for stopping with us this week. I hope you enjoyed the topic. This is Episode 3839 and 40 are coming up in the next month. And we’ve got some guests coming up. We’re going to be talking about dark patterns. Let’s go folks. We’ll be talking with some other stuff about hosting and things like that. I hope you’re going to enjoy it. I think you will. So stay tuned. We’ll be talking more about that as things progress. Other than that, stop by the website. We’ve tweeted about it. By this point, maybe if not, it will be soon. But there will be a post on the site. If you couldn’t make it to the accessibility summit, and you wanted to see my talk by chance. I don’t know why you would. I don’t know why anybody would. But if you did, there will be a post on the drunken ux.com site. I’ve got the slides and audio from that posted. So there’s a video there you can go watch. It’s about 40 minutes long give or take but it’s all about transcripts and transcript strategy. So go check that out if you want let me know what you think if you’ve got any other recommendations in that area that you would throw my way I would be happy to hear them especially if they help us get better faster and and whatnot at our transcripts, though Yeah,
that’d be cool. There was a one quick addendum there was an article that is gonna be in the show notes that I totally forgot about. The technical debt is like Tetris ever played the game Tetris with blocks falling. Sometimes you have to play some blocks of optimally, but as long as you clear violator, it’s fine. But if you place too many sub optimally, then it piles up and gets ugly.
As a big fan of Tetris. I love that metaphor. Isn’t that? Yeah, the fan of Tetris and metaphors. I love Yeah. Thanks for listening, folks. It’s been a year and a half. We’re going into the second half of our season right now is a great ride. And I have enjoyed it thoroughly. And I’m glad that you’ve been here with us for it. And I think when you’re on that kind of ride, there’s only one thing you can tell folks before you take off. And that’s to keep your personas close and your users closer by