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:31] 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 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 you. I think about it in terms of dependencies or the security, the state of security, and 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. Like they might still... The bits are all still there.

[00:02:44] Dave Adsit: Yeah. My merge SOAR and bubble SOAR in Java, those were still on the disk. They're still in perfect working order, presumably. Yeah. Provided you have a way to get them off the disk. I mean, obviously this isn't exactly 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.

[00:03:13] Allan Stewart: Yeah. Yeah. The world changes. I feel like this is related to technical debt, which we've discussed recently, but it's also kind of different, right? Right. 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 like 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, right? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. or DOS box 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. For sure.

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

[00:04:43] 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. Yeah.

[00:05:13] Allan Stewart: Yeah, because it's there. It's like frozen in time, right? It was in stasis. And it's popped out years later 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 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 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. Right? Like some of these weird things that would happen in like the NES days, it depended on that machine. Right? 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:01] Dave Adsit: 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 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. 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 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. You know, your SaaS business product, 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? Either... And even at the time, that might have been in flux when it was actively developed. And now you don't know because a lot of that context was lost 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 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, 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 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 learning. 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'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 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 expectations for how the software is going to work have changed drastically.

[00:13:55] Allan Stewart: I think also about the expectation of being able to work in that code. Certainly, we hear a lot about various legacy platforms and things. So can you find somebody who can write COBOL, who can work on your mainframe? Those are real problems that are happening. But I think about just how much the world has changed. 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. 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 entirely. Not entirely. Not entirely. 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 did a market analysis and these are the tools we need to use so that we're backward compatible with 2007 or whatever.

[00:15:34] Allan Stewart: So this makes me think about... There's a... There's a quote in Lewis Carroll's Through the Looking Glass, right? So this is Alice, Alice in Wonderland. And she's talking... 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... 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... OO is based on concepts borrowed from cellular biology. There's also a Red Queen hypothesis in evolutionary biology. Which is that every... Every... Every... 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.

[00:18:10] Allan Stewart: Yeah. Yeah. And we talked, you know, before about video games. I kind of feel like that's the video game paradigm, right? They are all projects. Yeah. 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, you know, 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 $1250. 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... 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, And I'm like, it is still a very fun game. But when I bought the copy of it this time, I paid $8 instead of $65. And when I bought it the first time, I got just the base game. And when I paid $8, I got the game and every expansion and 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. 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 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. Yeah. And a lot of businesses can't afford to do that. Right? They're not... They're not... The market doesn't think about it that way. They don't want... 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 have to make sure that that is constantly kept up.

[00:21:01] Dave Adsit: Right. And if you think about it, we've been... 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 1 in production because we haven't done the work to maintain it and upgrade it. Even though... Well, because, 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... 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... I've been... My head has been in the lean world for a long time. Mm-hmm. 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 a lot of time to do that. 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, 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? Yeah. To keep in that lean 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? Right. Because if you do it too fast, you're breaking things kind of for no reason because you're too quickly making change. And so it's a U-curve optimization.

[00:24:16] Dave Adsit: Yeah, it certainly is.

[00:24:17] Allan Stewart: If you take too long, then it's just so hard to make the change. 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've got 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. 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:16] Allan Stewart: 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 maybe call it rotted. Code. Yeah. 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 code rot. 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, it's different. It's changed.

[00:26:23] Dave Adsit: Yeah. I mean, that's a hundred percent true. The, the organic nature. I mean, I think that the garden is 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, 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. Yeah. Like 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 intend and that we planted purposefully. And you could, 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. It's in that regard that, and you have to pick where you put your effort. Right. Um, maybe there are some places, you know, there, there is a, there is an area, you know, you have a particular field or, um, 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 tell it all under next spring.

[00:28:30] Dave Adsit: Right.

[00:28:31] Allan Stewart: 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. That it just has me thinking about how you can't have a fully tidy code base because mess happens. I think that's, 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.

[00:29:29] Allan Stewart: Like a Zen garden.

[00:29:31] Dave Adsit: 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? Yeah. 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'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, I like the idea. 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 cleanest because it's the most habitable for you. You have, 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 re glued it and resealed it and re and put it on the ground. I would have 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 or for your biology to be constantly. You know, hyper clean and destroying all the bacteria like you need some of that bacteria. You can't you can't get rid of all of it.

[00:32:07] Dave Adsit: Yeah. So here's another analogy from 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 100 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 create.

[00:32:50] Allan Stewart: Yeah.

[00:32:51] Dave Adsit: 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. It 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. Mm hmm. And I wonder if it was unit tested. And sure enough, it had been unit tested. But the unit that 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 pattern. 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 weren't included in the build process. Yeah. And of course, by the time I showed up and 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: So they knocked over the garden hedge and then wondered why it continued to get worse and worse.

[00:34:29] Dave Adsit: Yeah. And then they 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. Yeah. Some of this discussion makes me wonder. Maybe this is one of. Some 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 code kata 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 of the coding value, but not the value of can you have Game of Life? Running because there's a million other implementations. Right. 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 if what you're trying to do is kind of explore that artistic side of the code, then maybe that's a great small garden that you're working in. Occasionally.

[00:36:30] Dave Adsit: Yeah, I like that a lot because no, I'm not going to ship my implementation of sort because 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. On my GitHub. Account that are never going to be maintained again. But they created value while they 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, you know, a relatively recent and you're, you're doing an okay job of keeping some things up to date. It might not be the, the shiny hotness that everybody's trying to put on their resume 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 SAS 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.

[00:38:57] Allan Stewart: Yeah. Yeah. 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 even then they probably are getting recompiled with every new compiler that comes out with every new distribution. So somebody is out there maintaining it or, 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 disc 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 it running. Keep that up to date.