Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the complexity of content security policy headers.

[00:00:32] Dave Adsit: I'm Dave Adsit, a VP of engineering. And recently I've been thinking about when process enables teams versus when it distracts or impedes them.

[00:00:40] Allan Stewart: Our episode topic is code rot. So I've sometimes heard that code doesn't get bit rot. In other words, the bits, they don't waste away. Maybe you could lose a hard drive or something like that so or the data can be taken away, but the bits, once they're written, they're just there. And I, I agree with that concept, but there sure seems to be this thing called, that's kind of a slightly different take on it, which we're calling code rot. How would you describe code rot, Dave?

[00:01:16] Dave Adsit: Well, I think that you're definitely right that the bits don't change over time just by existing on disk unless some physical thing happens to that disk, right? But the world in which that code exists is constantly changing and evolving. And because everything else is moving forward in time and those bits are static, it sure feels the same as when something is rotting actively in front of view. I think about it in terms of dependencies or the state of security in the industry as a whole or UX patterns that change over time. The code itself is still doing exactly what it always did, but it sure feels old and broken when you go to use it later. This will date me a little bit, but in college, I carried around my work on a zip drive, which is like a floppy drive, but for lots more data. I remember those days. I think I had a 100 gig zip drive that I used to carry my projects around on. If I were to find one of those disks now, I would have absolutely no way of accessing it. Zip drives just don't exist.

[00:02:41] Allan Stewart: The bits might still be there.

[00:02:42] Dave Adsit: Like they might still, are all still there, the, my merge sore and bubble sore in Java, those were still on the disk, that they're still in perfect working order, presumably, provided you have a way to get them off the disk. I mean, obviously this isn't exactly of a case where the code itself has rotted, but I did say Java, and I mean Java applets, and I don't know if you can run Java applets on any version of Java published in the last decade. Yeah, yeah, the world changes, and I feel

[00:03:16] Allan Stewart: like this is related to technical debt, which we've discussed recently, but it's also kind of different, right? Like, depending on the context, this code rot, it might be considered debt or some kind of subcategory, or it just might be this other thing that is happening to you kind of separately from especially when you're considering the metaphor of if you're taking on debt or not. But yeah, I agree. Things are more difficult to run, or it's less secure, or antiquated in some way that makes it feel like it's problematic. An example I think about is old video games. And they kind of show both sides of this idea. Because the bits haven't rot. The actual bits are still there. And they perform the game, right? And so sometimes that's great, right? You can get an emulator and play old games. And if the emulator is good, then they'll work perfectly fine. But if you don't have the right emulator or DOSBox or whatever it is that you've got, then they're basically unusable, right? You can't play the game.

[00:04:27] Dave Adsit: Well, and hopefully the version that you have of that simulates the right CPU speed.

[00:04:33] Allan Stewart: For sure. Sure. I definitely remember the days where there was a turbo button on my tower.

[00:04:42] Dave Adsit: 386 or 486?

[00:04:44] Allan Stewart: Yes, exactly. And there were some games that if you push that turbo button, they were really hard. Really hard.

[00:04:52] Dave Adsit: Yeah. I remember a version of Snake that was built based on how long it typically takes for the clock cycle to tick to the next cycle, right? And when we upgraded our computer, it was no longer playable whether you had turbo enabled or not. It was just too fast.

[00:05:12] Allan Stewart: Yeah, yeah, because it's, it's there, it's like frozen in time, right? Like, it was in stasis, and it's popped out years later with, with no knowledge of the world that's changed around it. And so what that means is, as far as, like, code rot, you might not be able to do a lot of stuff with this old game. You can't necessarily extend it, change the controls, upgrade the resolution, or do some of of those other things that we might equate with modern games. And when we were discussing this prior to recording, I thought it was really interesting that you talked, you mentioned that the game might be less fun because of this. The value is diminished. Right. It's like the game didn't change, but your expectations of the game have changed.

[00:06:00] Dave Adsit: That's exactly right. I think the thing that's happening there is the value of the software is going down for whatever value measurement you're using. And so even if the software isn't changing, it's becoming worth less to you as a consumer.

[00:06:18] Allan Stewart: So there may be old bugs, sometimes the features, like old versions of Mario where you could jump through the wall. And that's really related to that snapshot in time. A change in the hardware might change what happens with that. Some of these weird things that would happen in the NES days, it depended on that machine. You got certain overflows that behaved in a particular way, which is interesting, and it might not continue to work when you pull it forward. If your emulator is protecting you from buffer overflows, then suddenly the game has changed.

[00:07:02] Dave Adsit: Yeah. Yeah. So one of the ways that this is like raw in nature is that what appears to be strong and stable from the outside could actually be brittle and hollow on the inside. Like, if you're wandering through the wilderness or through a forest and there's a fallen log, you may look at it and think that it is perfectly capable of supporting your weight until you put your weight on it, and the whole thing comes crashing down. And you twist your ankle, and you are hopefully following the a buddy system and not stuck in the woods by yourself with an injury, right? That's how it feels when you try to take a dependency on one of these software systems that hasn't been maintained properly, kept up to date with the changes in hardware, the changes in the software ecosystem, the changes in all the things around that code that can affect how they can basically affect its value proposition. They can affect how it works without changing how it works.

[00:08:03] Allan Stewart: Yeah. Yeah. And that can be in the software itself, like the product, the features, right? Like we were talking about the game. You know, if it was a video game, you could potentially still play the game. But it can also affect the code itself, right? With video games, I mean, there's kind of a resurgence of, you know, a bunch of different places where you can get and play or subscribe to legacy video games, and that's fine, you just play them and enjoy it. But a lot of software doesn't resell very well that way, that you can't take the old thing and sell it again. Uh, you know, your, your sas business product from 10 years ago, maybe nobody wants to buy it in the state that it was at that time, and so you need to be able to pull it forward. But that code, in addition to what the product does, there's actually what the code itself is communicating to the developers. And that hasn't changed either. And developers might not know what is new, what is old, which patterns do we want to emulate? Which ones do we want to get rid of? And even at the time, that might have been in flux when it was actively developed. And now, now you don't know, because a lot of that context was lost as, as time went by.

[00:09:29] Dave Adsit: Yeah, I think any long lived software product that I've ever coded on has had that problem to some extent, where, you know, you hire a new developer, and they are starting to get acquainted with the code base. And they say, "Hey, I found that we have in this code base, some places where we do code in the HTTP controller and other places where we do code in these commands or query objects, command objects or query objects, and other places where we do code in these workflows or domain scripts or take your pattern, right? Like, there's 10 different ways that we interact with with the HTTP front end and the database back end and creating the business logic in between. And which one are we moving towards, and which ones are deprecated and we're moving away from?" And a lot of times it's unclear. And if nobody has touched the code for a while, it's even less clear which pattern we should be emulating, which pattern we should be implementing, implementing, which pattern is providing us the most value in this code base.

[00:10:46] Allan Stewart: Yeah. Yeah. And the old code doesn't contain your new learnings. Those could be industry-wide learnings. Oh, we realized that there's a better way to handle this, or there's new features and newer frameworks or platforms, but it could also just be your own individual learnings. The way that a developer has like enhanced their capability to deliver software. And those aren't present in the old code. And the code didn't change, but it's kind of rotted away.

[00:11:23] Dave Adsit: Right. Like, I don't suppose too many people are doing web forms anymore. But when I first started doing web forms, I put everything, all the code in the controller untested. And then when I learned how to test, we were using the model view presenter pattern where you had a presenter and you injected a view and you wrote to the view, and you could test the presenter really well. And then later we went to a model view controller pattern, where the controllers were intrinsically testable, and we didn't necessarily do the same level of abstraction, or we didn't do do our abstractions and dependencies the same way. But we were still able to do testing. And definitely it's an improvement to the system as a whole that comes with additional learning, right? I learned how to test. I learned the value of writing automated unit tests. I saw it save me many times from my own dumb mistakes. And so I wanted that benefit with new code that I wrote. But if you just looked at a code base that I'd been working on for a long time, you might find all of those ways of doing it together.

[00:12:33] Allan Stewart: Yeah.

[00:12:33] Dave Adsit: And so that, I mean, that's kind of an example of both learning on a personal level and on a team level, but also the technology itself changing. Now, a lot of times we don't even build what you would consider HTML views in our server side code. We build APIs and we do all of the HTTP client side stuff in the browser using tools like React. And that's one more step removed. That's one step further down the path of technology improving, our understanding of technology improving, and the expectations of users also changing again. We used to think that having basically a dumb view in the browser that interacted with a server to do everything was actually not just completely adequate, but also pretty amazing and novel and new. And we're now at the point where we build entire applications inside of the browser that sit on server-side APIs that run in the cloud. And so the, the expectations for how the software is going to work have changed drastically, I think

[00:13:56] Allan Stewart: also about the expectation of being able to work in that code. Um, certainly we hear, you know, a lot about various, uh, legacy platforms and, and things. So, like, can you find somebody who can write COBOL, who can work on your mainframe? Um, you know, those things, those are real problems that are happening. But I think about just how much the world has changed. Like if I went back to some of the old JavaScript that I wrote, even some of that, even the ones that still run properly, it can be harder to understand and work through. Because even though browsers have done a reasonable job of continuing to be backwards compatible, you've still got the issue of understanding it as a person. And can you find somebody who can work on it, who can understand what this old code is and does, or even wants to? It just might not be palatable. It's like, no, I'd rather just not work in that at all.

[00:14:57] Dave Adsit: I'm fairly certain that if I took our most senior front-end developer on my team and said, hey, we're going to do this next app that we're building, not in Next.js, but instead in jQuery and Backbone, he would just quit. He would at the very least quit the project. He'd be like, "I'm sorry, I can't do that, I can't do that, Dave." Like, "no, but we've, we, and we did a market analysis, and these are the tools we we need to use so that we're backward compatible with 2007 or whatever." So this makes me think about

[00:15:36] Allan Stewart: there's a quote in Lewis Carroll's Through the Looking Glass. So this is Alice in Wonderland, and the Red Queen is talking to her. And she says that here in Wonderland, you see, it takes all the running you can do to keep in the same place. And I feel like that happens a lot. And we see it in, like, the project versus product mindset. But there's a lot that you have to do in software to keep relevant, to keep being able to stay in that same place, that same place of not code freeze, but sort of code momentum, I guess, that you're not kind of drifting to a stop. Even if you're not accelerating and growing, you don't want to be losing your customers either.

[00:16:32] Dave Adsit: Yeah, I think that's 100% true. I think about that a lot. I obviously have always been interested in biology, right? And I think a lot about things, concepts from biology as they apply to software. A lot of things that we get like, oh, oh, is based on concepts borrowed from cellular biology. There's also a Red Queen hypothesis in evolutionary biology, which is that every organism is in competition with its predators, its prey, and its parasites. And every organism is running as fast as it can just to keep up with its predators, its prey, or keep away from its predators, keep up with its prey, and keep out of the way of its parasites as well. And if you are not moving constantly, if you're not improving, evolving, whatever constantly, you run into trouble really quickly. And I think that that very much applies to software products. The project mindset is definitely a mindset that ignores the ongoing long-term cost of maintenance, or perhaps intentionally chooses to defer it until a later date. And as we know in software, "later" means never. "Later" means next time you want new features, and you realize you basically have to upgrade the entire thing in order to implement the one new feature that would have been so easy if you had already upgraded. Yeah, yeah, and we talked, you know,

[00:18:12] Allan Stewart: before about video games. I kind of feel like that's the video game paradigm right there, they They are all projects.

[00:18:19] Dave Adsit: Yeah.

[00:18:19] Allan Stewart: You start a new project. You get it out there. You deliver it. Now it's in the world. Hopefully people play it. But you're not expecting to support it for 20 years. You're expecting for it to go away. And maybe you'll sell it on the emulator system to get a few bucks down the line again after people have kind of forgotten about it and want to try it again.

[00:18:46] Dave Adsit: Well, I was going to say all of your value comes right at the beginning as well, right? You write a new flagship game for Nintendo Switch, you sell it for $60 to $80 an instance per license, right? People buy it. And then two years later, it's down to $30. And then two years after that, it's down to $1,250. And then it's, you know, on a flash sale for five bucks. And you're like, this was an $80 game, but now it's only $5 because five years later, expectations around what the game is going to do, around what makes a game fun, have all changed. I recently repurchased one of the games that I played through it when it was new, and I had a huge amount of fun. And then it kind of came back around as, like, "oh, this might be interesting." And I'm like, it is still a very fun game but when I bought the copy of it this time, I paid eight dollars instead of 65. So, and when I bought it the first time, I got just the base game, and when I paid eight dollars, I got the game and every expansion that and an add-on that's been released in the last seven years. So the value is definitely a lot less, or at least the value accrued to the developer, to the owner, to whatever, right? Right. Um, I'm still having fun, but if they told me that it was still 65 for a game that's seven years old, I probably would have just passed on it, and they would have gotten nothing.

[00:20:11] Allan Stewart: Yeah, yeah, so you have to keep, you keep having to move on, and, uh, in that project mindset, moving on means you start over, you, right, because they're not just sitting in place either, it's just that they're leaving all the baggage behind and starting a new thing. And a lot of businesses can't afford to do that, right? They're not, the market doesn't think about it that way. They don't want to have to buy a new copy for 80 bucks every year. Instead, they want it to just continue to work. A lot of, especially SaaS products fall into this category. And so you have to do all that running, carrying all the baggage of your code with you, and, you know, have to make sure that that is, uh

[00:20:59] Dave Adsit: is constantly kept up, right? And if you, if you think about it like we've been talking about HTTP web front ends type of thing, right? There's a new JavaScript framework all the time, and there's an improvement to the existing JavaScript frameworks all the time, and some of us still have Angular one in production because we haven't done the work to maintain it and upgrade it even though, well, cause you know, Angular 2 was almost a rewrite. It was so, it was substantially different from Angular 1. And so we, you know, maybe we didn't go to 2, and by not going to 2, we made it a lot harder to go to 6, 8, 10, 14, whatever the current version is. And besides, all of your JavaScript developers, all your front end experts want to work and React anyway. So what are you going to do? And so if you haven't been maintaining it, you're still paying the cost of having not done that maintenance. One of the things I like to think about, my head has been in the lean world for a long time. Lean software development, lean manufacturing, theory of constraints, all of that stuff. And one of the concepts that's very prevalent there is total productive maintenance, which the idea is that you do enough maintenance to maximize the value produced by your system. So in manufacturing, if you have a machine that stamps widgets, you don't run that machine 24-7, 365 until it has a critical failure and you have to take it offline until you can fix it. You run it for 23 hours a day and spend an hour a day oiling it and replacing any worn parts or whatever. And that way you maximize the value long-term. Or you take it offline for a full system diagnostic and overhaul once a month or whatever. You are doing regularly scheduled maintenance to prevent the kind of failures that we're talking about. So if you say, hey, every week we're going to spend two hours upgrading JavaScript dependencies, dependencies, then you don't find yourself suddenly four years later with four years of JavaScript dependencies that are all out of date. And now you can't install the new thing that you need because you would have to do that cascading update of every single component of your front end.

[00:23:29] Allan Stewart: Right. And you're also keeping your batch sizes small, right? To keep in that lean concept, concept, right? If you're upgrading as quickly as you can, as often as makes sense, that's not to say that you have to be doing it every day.

[00:23:45] Dave Adsit: I mean, it can definitely be overwhelming. There's a new update every single day. You don't want to spend an hour every single day doing updates. Maybe three hours once a month or something would be enough to keep your JavaScript up to date.

[00:23:59] Allan Stewart: Right. And when you do it, then when it's small, right? Because if you do it too fast, it might, you're breaking things kind of for no reason because you're just, you're too quickly making change. And so it's a, it's a U-curve optimization. Yeah, it certainly, if you take if you take too long, then it's just so hard to make the change. Um, like you were saying, you've got so many breaking changes to go from version 1 to version 17 that it's hard, and so you got to to keep it up as you go.

[00:24:34] Dave Adsit: Yep. But if you do it too quickly, you are paying the transaction cost of doing updates too often. And that's also not the optimal value curve. Like, as software craftsmen, crafters, we want to maximize the value produced while minimizing the effort expended, right? That's our goal. Let's create high value for ourselves and for our customers, our clients, our users, our business. And so we have to find somewhere in the bottom of that U-shaped curve where it's kind of flat and it's like, this is about the right cadence for us. Maybe it's every two weeks or every four weeks, but it's not every day. And it's certainly not once a quarter or once a year.

[00:25:15] Allan Stewart: Yeah. Recently I heard on another podcast, Kent Beck was talking about how the code that you touch all the time is the code that you think of as clean. Unclean code is the stuff that you leave alone and don't touch. Right. So, or in this context, we'd maybe call it rotted code.

[00:25:33] Dave Adsit: Yeah.

[00:25:34] Allan Stewart: I thought it was interesting. He talked about, you know, except for maybe some small toy projects, you can't really have a fully tidy code base because mess just happens to you. Like the world changes, all these things that we were talking about with CodeRot. And so he calls it, so he said it's more like a garden than a sculpture. You can build a sculpture once and, you know, it'll, it'll last for a long time, right? When I went to France, I got to see some really cool sculptures. Some of them were pretty eroded, but they were still really cool. And they're still there made out of marble. Yeah. But a garden, you can't really go into the same garden twice, right? Like, just like you can't step in the same river twice. It's different. It's changed.

[00:26:23] Dave Adsit: Yeah. I mean, that's 100% true. The organic nature. I mean, I think that the garden is a a little bit different in that it's constantly growing and changing on its own, whether you're changing it or not. And code, if you're ignoring the code, it can stay kind of stagnant or stale, stable. It doesn't change on its own, typically. If it did, I think we'd have a different set of problems, but we'll talk about AI later. But the code, if you're not changing it, it's not changing, but that doesn't mean that everything else around it isn't also changing, right? So So one of the things that we find in our garden is that we spend as much time fighting weeds as we do enjoying the things that we planted purposefully. And you could think of the updates you didn't ask for as being kind of like weeds. You have to go take care of them or else they will overwhelm the garden and the value of what you planted will be diminished or destroyed.

[00:27:26] Allan Stewart: Yeah. Yeah. I like that metaphor. I, you know, even though it's not perfect, no metaphor is right. Right. It's like our friend, Mr. Box, who says that all models are wrong, but still some are useful. It fits in that, that gardening is kind of how we have to look at maintaining code. You can't just let something sit completely follow. There's, there's always maintenance. There's always something to do. No matter how much time you spend doing maintenance, there's always more maintenance. And so the metaphor fits in that regard that, and you have to pick where you put your effort, right? Maybe there are some places, you know, that there is, there is an area, you have a particular field or, you know, planter box that you're just going to be fallow this year because you just don't have the time for it. And, and yeah, the weeds are going to go crazy in there, but you're okay with that because you're not going to try to actually let anything else grow. And you're just going to till it all under next spring. And maybe that's okay with software too, but there's other places where you're trying to actually make it good, make it useful. You're, you're planting something that you want to grow because it's, you know, beautiful flowers or, or vegetables or something that you actually want to get value out of.

[00:28:49] Dave Adsit: Yeah, it just has me thinking about how you can't have a fully tidy code base because mess happens. I think that's interesting, a super interesting concept because if you were to spend all of your time just cleaning the code, you might derive some fulfillment as an engineer from that. But it would be more of an artistic adventure than a craftsman or crafters type adventure, right? Because you're putting a lot of effort in, it's a lot of expense, but you're not really increasing the value very much, like a zen garden. Yeah, it's like, it's not to say that you shouldn't do that, it's to say that that may not be, there may not be a positive ROI on that type of effort, and because we all work in business, I mean, we talk about doing the right thing at the right time with the right tools. The right thing at the right time with the right tools often means increasing value. And what is the value? I mean, that we could go down another whole rabbit hole on what is value, but I mean, value is what you want, right? And if what you want is a perfectly tidy code base, then you are not producing some kind of customer value or user value. You. You're certainly not increasing it with new functionality and new features because you are spending all of your effort on refactoring existing code to be as efficient or effective or whatever is possible to have the perfect variable names, the perfect whatever. So I like the idea that the code that you touch the most often is going to be the code you think is the cleanest. I noticed that he didn't say it is the cleanest. It's the code you think is the the cleanest because it's the most habitable for you. You are the most comfortable in that area. It's like when I was a kid, there was one stair that always squeaked, and I just stepped over it because I didn't want it to squeak. That doesn't mean it was a good staircase. I mean, ideally I should have taken that stair tread up and re-glued it and resealed it and put it back down, and then it wouldn't have squeaked, and that would have been better. But instead, because I use those stairs multiple times every day, I just stepped over the stair that squeaked. Right. And so because we inhabit that part of the code, that part of our system, we come to think of it as the cleanest part of the system. And there may be other parts of the system where a lot of work has been put in to make a clean code base. And because of our lack of understanding or knowledge or whatever, we don't, we don't believe that it's clean.

[00:31:31] Allan Stewart: Yeah. It makes me think about like hyper sterile environments, right? Like a, like a clean room. Yeah. Yeah. We're maximizing for cleanliness. And there's a reason to do that sometimes, or like at a hospital, you probably want to keep things clean, but it's, it's not as livable when you get that, when you get that clean, it's, in fact, it can actually even be harmful for you for your biology to be constantly, you know, hyper-clean and destroying all the bacteria. Like you, you need some of that bacteria. You can't, you can't get rid of all of it.

[00:32:06] Dave Adsit: Yeah. So here's another analogy from biology. I have a two-year-old and a two-year-old in clean rooms are not compatible. Even if you had a clean two-year-old that you took into the clean room, I'm fairly certain they would immediately contaminate the clean room. But also two-year-olds have a growing immune system. And if you keep them away from bacteria, it does not get strong. Our pediatrician has said, "kids have to get a hundred childhood illnesses before their immune system is truly strong." Like, well, where do they get them? They get them from other kids. They get them from school. They get, like, right. So there, there is a benefit to, to not being in that perfectly sterile environment. Value is creating. Yeah, one of the things that I've, you got me thinking of is an experience I had where there was a code base that everyone on the team thought was awful because it was overly complicated, blah, blah, blah, and I went in to look at the code base because we had to make an enhancement to it, and I was dreading it because I had heard all these horror stories. And I go in there, and I look at the code base, and I found that they were using some very, very common patterns of software development that were specifically intended to enable automated unit testing. And I was like, "Well, this is really weird because everybody said this code is bad, but it looks really good to me." And I wonder if it was unit tested, and sure enough, it had been unit tested, but the unit, the team that originally wrote it, handed it off to a different team for maintenance. And the team that was doing the maintenance didn't understand unit testing and didn't understand the patterns. And so they thought the pattern was too complicated, and they thought the tests were too brittle. And so they ignored all of the tests and kicked them out of the project entirely. They were on disk, but they weren't included in the build process. And of course, by the time I showed up with different knowledge, different learning and experience, right? I was like, "Oh, this would be helpful if these tests worked." But it had been so long since they had been ignored that they no longer would pass. And I didn't have time to do the appropriate maintenance to bring them all up to spec with what was being done in the project at that point.

[00:34:22] Allan Stewart: And they knocked over the garden hedge and then wondered why it continued to get worse and worse.

[00:34:29] Dave Adsit: Somebody let in some goats or something. I don't know, but that garden was never the same again. I think the same thing happens with UI tests a lot. UI tests can be brittle, and if they're not maintained effectively, they can easily get to the point where you would rather just throw them away or rewrite them than try to do the necessary maintenance to keep them functioning.

[00:34:54] Allan Stewart: Yeah. Some of this discussion makes me wonder, maybe this is one of the things that I really like about code katas. Because I enjoy writing code, but when I'm not working, I'm more likely to be found doing some kind of small toy project like a kata. And I wonder if that's kind of playing off of these different aspects, right? Because you can have different reasons to have a garden. Sometimes you want a garden because it's beautiful. And other times it's got some kind of utility, like your vegetable garden or you're growing something useful. And maybe the Codecada is a place where you can have more of that Zen garden and you can just continue to iterate, continue to play with it, try something new. You're not really generating any new value, right? Like, I don't think any of the implementations I've ever done of Conway's Game of Life have generated any more value to anybody, except for me. It's sort of an intrinsic value, the coding value, but not the value of can you have Game of Life running? Because there's a million other implementations. There's some that are vastly superior to the toy ones that I've done. And you can just go, if game of life is what you want, you can go get another one real easy. Yep, but but if what you're trying to do is kind of explore that, that artistic side of the code, then, then maybe that's a great, great small garden that you're, that you're working in occasionally.

[00:36:30] Dave Adsit: Yeah, I like that a lot, because no, I, I'm not going to ship my implementation of sort, because it's It's probably bubble sort and not very good anyway. But I might write a bubble sort just to practice dealing with loops or iterators or whatever if I'm in a new language or, and I might do it multiple times, but I know I don't have to maintain that code and it's okay with me if it rots. I've got projects on my GitHub account that are never going to be maintained again, but they created value while they existed existed and there isn't value in maintaining them long-term. In fact, it's probably easier to just write them again. I don't even know how many times I've written an implementation of Game of Life. It's got to be in the hundreds now, given the number of code retreats I participated in. And I don't think I have the code for any of them. The value they created was in the learning along the way and hopefully the opportunity to apply that learning down the road. But if I had to maintain all of those 100 versions of Game of Life that I've written, I mean, that would be all the coding that I do is just maintaining those. Yeah. And so maybe it's okay for some code to rot and maybe it's really, really bad if other code rots.

[00:37:50] Allan Stewart: You definitely have to pick your battles. And in most places that I've worked at, the code base is big enough that you can't get to it all anyway. So you have to choose. And so you might not be happy with where you're at with your tech stack, but maybe it's fine. If you're on an unsupported version, that might not be fine. But if you're on a relatively recent and you're doing an okay job of keeping some things up to date, it might not be the shiny hotness that everybody's trying to put on their resume right right now. But the value that you're trying to get out of the software probably isn't in the tech stack. I don't know anybody who buys a SaaS product because of what tech stack it was built on.

[00:38:37] Dave Adsit: Yeah, only engineers would ever even ask. This reminds me of that Dan North quote that "functionality is an asset and code is a liability." Nowhere do you realize that your code is a liability more than when you find something that's been rotted through lack of maintenance for five or 10 years. Yeah.

[00:38:58] Allan Stewart: Yeah. The only counter example that I could even think of is maybe something like Unix tools, like a word count. I don't know if word counts ever changed in its core implementation. Maybe, you know, maybe there's some vulnerability that somebody found or, or something, but but But even then, they probably are getting recompiled with every new compiler that comes out, with every new distribution. So somebody's out there maintaining it, or at least maintaining some aspect of it. And maybe that's the key then, is we just have to have this recognition that code rot is a thing. Bits don't rot. The bits will still be there. They'll still be intact as long as your disk didn't get left out in the sun for too long. But the code and the functionality, like what you're getting out of it, the value, that erodes away. And so you have to do something about it. You have to continually be working at it if you want to be able to keep that up to date.