Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode six of 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 recently I've been thinking about data warehousing.

[00:00:13] Dave Adsit: I'm Dave Adsit, CTO, and lately I've been thinking a lot about planning and batch size in relation to refactoring versus rewriting a component.

[00:00:23] Matt Baker: I'm Matt Baker, software architect. Lately I've been thinking about the balance between getting a product to market and doing so with quality code.

[00:00:32] Allan Stewart: Today's topic is deleting code. So to kick things off, why would a professional, somebody whose job it is to write code, want to delete code? Isn't that the opposite of what we're getting paid to do?

[00:00:47] Dave Adsit: Yeah, you would think. I really have been thinking a lot this week about batch size. And rewrite versus refactor. Part of it is a project that one of my teams is working on right now, where the code is just, it's too bad to fix iteratively, or so I've been told. And I also attend the Utah SC meetup, and we did the Gilded Rose Cata recently. The way I chose to tackle Gilded Rose this time, which is a refactoring cata where you're intended to take small steps. And iterate towards a good solution. The way I chose to tackle it this time was write a whole bunch of tests for all of the behavior that's described and all the behavior that I could observe. And then throw all the code away and start over because it was just terrible. So I feel like I got to a good solution far faster by doing that than by iterating slowly the way I typically teach my team to do. The bad code was so bad. It was just in my way and I couldn't think through the transitions that I needed to make to get from where it was to where it needed to be. But I knew I had a safety net with my tests so I jumped in with both feet.

[00:02:09] Matt Baker: What was it about the code, Dave, that got you to this conclusion that it was just, it was time to delete the code instead of even trying to refactor it?

[00:02:16] Dave Adsit: Well, in that case it was struggling with it for a while. Like inlining things and extracting things. And flipping if statements. And that code in the Gilded Rose very intentionally has very high cyclomatic complexity. You know, there's if statements within if statements within if statements. And I combine them and I split them. And the code was moving around a lot but it wasn't really getting better. And so I felt like I was stuck. You know, I was just stirring the soup. And I really wanted, after reading it. And reading what it was supposed to do. And reading through my tests. It was supposed to do some pretty straightforward things. And there's some constraints in the Gilded Rose that you have to follow if you want to do it the right way. But I just, I couldn't find the transitions that would take me from green test suite to green test suite without ripping up huge sections of it. And so I finally just said, what happens if I treat the existing code as though it were comments and delete it. And start fresh with implementing it.

[00:03:24] Matt Baker: Yeah. That clean slate is definitely attractive to me sometimes. And it's also I feel like remarkable that you're able to delete all the code like that when you had those tests. And I know for me personally, if I did not have those tests, there's no way in maybe like a production setting I would delete that code like that. I just wouldn't do it. But with those tests in hand, I feel like all of a sudden you're free to almost short circuit maybe the refactor exercise.

[00:03:48] Allan Stewart: It gets to an interesting topic about, well, what is the value of content? The things that the code does for you, the features that come out of it, those are certainly valuable. But the code itself, does that have value?

[00:04:04] Matt Baker: There's this interesting question. I did a workshop with Dan North who at the time was at ThoughtWorks. I don't know where he's at now, but I hope he's somewhere in the world talking about code quality. He had us all stand up in a room. There were maybe 20, 25 of us. And he said, if you believe code is an asset, go to one side of the room. And if you believe code is a liability, go to the other side of the room. And it was pretty evenly split. And then throughout the course of some conversation, some people moved one way or the other. I found myself uncertain at first and pretty thoroughly convinced that code is a liability by the end of the workshop. And it came down to this simple truth for me. The more code you have, the more problems you have, and the more elegant solution or the more elegant a solution is often is measured by how many lines of code it is. If you can say something, if you can express it simply, we call that better. Well, I call that better. And so through the course of that workshop, I realized that more code, more problems. And the best code is no code. And usually reality finds you somewhere in between. But I definitely gravitate towards no code and that code is a liability.

[00:05:14] Dave Adsit: So the thing about code is that the best of code expresses an intention, right? But it expresses the intention. And so the more code you have, or even as you have any code, you'll find that you have introduced assumptions and coupling and you've fixed the way people think. One of the cool things that I've been able to do is do a lot of workshops with a lot of people. And you can manipulate a group, even a very smart mob, by writing the first line of code. As soon as you have one line of code, you suddenly have an architecture that people build on. And if you do that a few different ways with a few different groups, it's really intriguing to see where they end up, if they can even solve the problem at all.

[00:06:10] Matt Baker: For some reason, it reminds me of like a negotiation, like who's going to set the anchor.

[00:06:16] Allan Stewart: Yeah, yeah, totally. And it's because code becomes a constraint almost immediately. On what you can do next. It's software, not hardware. So you can change it. But there's an inertia there. And it starts building up immediately. Woody Zool of mob programming fame, he did a workshop that I attended one time where he did a constraint exercise where basically everybody took a stack of sticky notes. And on your sticky note, you put a hash, like a tic-tac-toe grid. And then he said, okay, everybody put in numbers, one through nine with no repeats. Okay, everybody can do that. One, two, three, four, five, six, seven, eight, nine. Great. Done. But then he started adding these other constraints. He's like, oh, well, but the top has to sum to this number. Okay. Well, now the top has to still sum to that number, but the side has to sum to this other different number. And now the diagonal has to sum to a third number. And he timed each progressive round. It's like, what is taking so long? It's just nine numbers in a grid. And software is that way. It gets more and more complex as you add things up. And so I agree with your assertion, Matt, that I think it's a liability. What you can do with it is an asset. But the liability is that as soon as you've put down even that little bit to start off your code cata, you've anchored. And now it provides at least inertia that directs what you can do with it going forward.

[00:07:42] Matt Baker: It's a sneaky one, too, because it's not a building on a hill. You can't look at it and say, okay, if I want to manufacture cars, I'm going to build a car. If I want to build cars instead of lollipops, I'm going to have to change my factory line. It's not so apparent to you. It's ones and zeros on a hard drive. And if you don't have kind of an in-depth appreciation of that, I think you can kind of forget that pivoting an existing code base is totally dependent on what Dave said earlier, the lens that the code was written through. And the understanding of the problem at the time, it was essentially codified. And if the delta between that and where you want to pivot is substantial, it can be difficult. And at that point, I think everyone would probably, well, I would wager that everyone would agree that the thing that's preventing them from pivoting is a liability.

[00:08:32] Dave Adsit: To that point, a few years back, I sat with a group and we were doing a SWOT analysis. Don't ask. But anyway, in the SWOT analysis, one of the things that you list are your assets, right? And we're like, what are our assets? What is helping us? And someone wrote down our software architecture. I don't know. I was like, oh, awesome. We have a great software architecture. What about it makes it an asset? And it was the fact that it's flexible and extensible in a lot of different directions. And then over the course of about a year, we realized we didn't need to flex or extend in any of the directions that were made easy by the code base that we had. We needed to go in a bunch of other directions that were made harder by that extensibility that we didn't need. And we steadily moved. And we steadily refactored that code and deleted a bunch of extension points in order to make the code simple enough to add the new functionality that we needed for our business to succeed.

[00:09:34] Allan Stewart: Yeah. And that stuff happens all the time. One of my teams right now is dealing with basically that exact problem. And I think about it, too, in terms of the world changes around us. If we think about code as an asset, it's like, oh, well. Is that COBOL code that was written 40 years ago, is that an asset? I mean, maybe it depreciated all its value. That depends.

[00:09:56] Dave Adsit: Is it 1999 and you're a COBOL programmer charging $550 an hour? Because it might be.

[00:10:04] Allan Stewart: It goes in waves with different languages. You know, I know, Matt, you've done a bunch of VB.net in the past. Don't tell anybody. Maybe that's not the most valuable code anymore. I wrote ActionCode.net. I wrote ActionScript 3 with Flash. Now the browsers are getting rid of it. There's even a couple cases where specialty browsers have come out just to resurrect it for a site because they're like, oh, we need this site to run on Flash still. But the world has gone away from it. And Google is trying to kill it. Adobe even has disowned it. So the world changes around us. And then all of a sudden the thing that was bringing value becomes this huge liability. And it's not because the features changed. But it's because the code is no longer useful in the way that it once was.

[00:10:51] Dave Adsit: I was going to say, if you think about a business, the business is going to continue moving forward and going to continue having a lot of similar needs. Right? Businesses tend to evolve slower than the code base. And part of that is because you have to keep feeding your code. You know, we say once you've written it, it's good. Right? But is it? Do you have the latest patches on? Has somebody discovered it? Has somebody discovered a new vulnerability in the, I don't know, crypto library that you were using, for example? If so, then you need to do an update and validate that the update still works. And then you need to release it. And now what have you gained? You've gotten back to where you were. Right? So in that way, that code was a liability for your company. I agree.

[00:11:40] Matt Baker: One thing I like about this model is you're highlighting that even the most perfect code is subject to a lot of external factors that can render it useless. I have a little quip I like to describe this when it goes like this. You can either exploit volatility or be exploited by it. And I say this in like executive meetings and sometimes meeting where I've just kind of stared at after I say it. I don't blame them. It's a super like abstract and pithy thing to say that probably means something to me and nothing to anybody else. But what I'm trying to say is, look, the world around you is a place where you can have a lot of Well, depending on the space you're in. So the more you're like a commodity, the less I believe this is true. So if you've gotten to the point where your space is, I just need to produce this known quantity as fast and as cheap as possible. I think that you're playing a different game than what I want to talk about. What I'm talking about is when you're in a highly variable space that's changing for any number of reasons. Right? So the volatility is way up. And I think that you can exploit that by minimizing your code footprint, refactoring constantly, making sure that your, you know, your code is tracking with the business strategy. Right? Or I think you can be exploited by it when you dig your heels in the sand and say, no, we have a framework here. It says microservices architecture and it's on this stack and we can't ever change that. And we can't embrace this new pattern, even though the business strategy requires it because it's against the common library we build over here. And all these things, you know, they add up to, I believe, a bit of an entropy that you do get exploited by if you're not careful.

[00:13:12] Allan Stewart: Yeah. And there's just all these different ways that it becomes a liability. Even just adding a new person to your team and they have to figure out what do I do about this code base? Understanding the code base. And so I've come to think about it in terms of kind of a U-curve optimization. If you have a lot of code, it's just generally bad. There's too much. People can't understand it. They can't wrap their heads around it. There's probably a whole bunch of blind alleyways that people get sucked down into and, you know, vortexes and dragons and all kinds of things. But if you have too little, that's probably not good either. You need enough code to be able to express the features in a simplistic way. And don't do any more than that. But also don't try to, like, reduce it to one line and like, hey, we can shorten all of our variable names and we can collapse this down. Like, we could run a zip compression on the whole thing and pretty soon it's inscrutable. Nobody can understand it anymore. There's a good spot. And it's on the small side. But it's not too small. And so that's where I think that deleting code really helps us manage the risk of the liability that it presents. Right? Like, you have to have some code. You can't have no code if you're going to be in most software businesses. But you can reduce how much you have. And you do that by deleting some code.

[00:14:31] Dave Adsit: Hopefully what I'm about to say doesn't get any of us, particularly me, lynched by our physics friends. But code has inertia. It has no mass. But it has inertia. And I think about the fact that you have to take a code base and turn it slowly. The bigger it is, the more complex it is, the harder it is to change its direction. And for most businesses and most products, the thing we prize highly is being able to adapt quickly to the changing market forces or conditions on the ground. You know, we talk about how the software startup eats the software giant unless they just do it. And they just get bought out by them. Or whatever, right? But you see all these companies that set up their own internal disruption teams or innovation teams or laboratories or whatever. And it's all so that they can remove the inertia of the existing system and allow someone to go fast and figure something out. I remember reading that the captain of the Exxon Valdez knew like 15 minutes ahead of time that he was going to hit the shore of Alaska. Yeah. And pour oil all over the ocean. But he couldn't do anything about it. And we've all been in code bases where that is also true. You know that the code itself is so big and so hard to turn that it's going to crash the company into the coastline of Alaska. But you can't stop it. Which, you know, that's part of why we need to be deleting code to reduce that mass of code. So that we do have more agility and we can take it in the direction we need for our business.

[00:16:18] Matt Baker: Yeah, I agree. To stick with your boat metaphor, like you can take the big ship down to the dinghy or something like that, right? The little raft that you can pivot on quickly. I've been thinking a lot lately about this model of see an idea in the market, go build a solution for it and profit. And there's also this other model that a lot of people do where they see an idea in the market. Go out and raise it. Raise a ton of money. And then they kind of hail Mary. You know, I hope that by the time this money runs out, I figured out a way to make more of it. It's the game that some of them are playing, you know. And whether you like it or not, that's, you know, I think a different conversation. But what I will say is it's a highly volatile space. And so I think if you're in that space where you're trying to, you're racing the bank account reaching zero, be careful. You know, I think what we're talking about can really benefit groups like that. And so I think if you're in that space where you're trying to get a bunch of code really fast to try and find a fit and you don't have the money to refactor it to a different solution or you don't have the time, it just, it's a pretty vicious cycle you can get into. And sometimes at the end of it is going out of business, you know, and that's, boy, that can be a rough ride.

[00:17:32] Allan Stewart: So one of the areas where I feel like deleting code makes the most sense where it's like, this is just a slam dunk. Do it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. That's all there should be to it. They don't want to get rid of old code. Source control notwithstanding, no, we might need this later. Or I don't understand it, and so I'm afraid to get rid of it. There's a tendency to just keep piling on. We'll add more code. We'll just write new code and leave that scary code over there just in case somebody calls it or is using it somehow in some edge case of the system. And it doesn't take very long before that becomes a problem where you don't know how the system even works anymore. Deleting code is like removing debris so that you can actually see what is actually going on within the code system, and you make it smaller and better all at the same time.

[00:18:49] Matt Baker: I really like your debris metaphor, what it makes me think of. And I'm going to say this, but first acknowledge that I've done this. I believe that some people use their code bases as a chance to build a monument to their own cleverness or their own ingenuity, right? Where it's like, oh, these people. These people are not going to see this generics method coming or whatever. Whatever metaprogramming, whatever regular expression to discover a function to invoke at runtime. Just random examples, you know what I mean? We all do it. I've done it, and I know other people out there have done it. But it's funny that that clever code that you were stoked on, someone really probably hates you for. You know, because you talk about debris. I mean, these buildings eventually turn to rubble when you try to pivot. And it is debris. You're staring at this thing like, what does this regular expression do? Like, what does this function do? It's cool because it's like a triple high order function that's composed of all this pureness and whatever. But I'll tell you, I don't know what it does. And what this conversation is making me think about, one of the ways that you can maybe stay closer to code you can delete and maintain is maybe write simple code. You know, maybe I know for me, I, as of late, have been really, I've been writing a lot of Go. Yeah. And so I think that I'm sure that has a hand in it because of that language is philosophy. But, boy, it's nice when, like, everything's an if statement or, like, there's only one way to do a loop. Or, like, the compiler fails when you didn't use a variable you declared. Like, those kind of things, I feel like they drive me towards simple code. They don't even have generics, although I think they're considering adding them. And anyway, so there's this relationship that I'll just have to think about more between the ability to delete code and your. Whether or not you can control your desire to show how smart you are in your code.

[00:20:42] Allan Stewart: Yeah. It reminds me, there was a time where I was working with a developer. And he was a super nice guy. I really, really liked him. And he called me over and said, hey, you know, check out this code. Isn't this code great? Let me walk you through it. And it was divided up into a bunch of classes with inheritance. And I looked at it for a little bit. I'm like, this seems clever. And he looked at me. And he's like, when you say it like that, I don't think clever means a good thing.

[00:21:12] Dave Adsit: Yeah.

[00:21:13] Allan Stewart: And it wasn't. But I've also been there. I've been the one writing a clever piece of code when I probably should not have been.

[00:21:24] Matt Baker: Yeah. It's making me think about, and I don't know who this person was. So I don't know why they called you over. But I suspect they were proud of their code in some way. There's probably some version of this code is valuable in their mind. Right? Like it's elegant. It's terse, whatever. For sure. And it's interesting that I don't know how the conversation went, but I would wager through the course of conversation. At no point did they say, and it solves this business problem super elegantly and reduce the bottom line or, and it added to our bottom line by 20%. Right? Like oftentimes I've noticed that those parts of the conversation are missing. And I believe that's the really only metric of whether or not the code is valuable. You know, you, you're there to solve a business problem. Did you solve the business problem? And there are ways of doing it better. Like if it's elegant code. If it's code, you can refactor if it's clean, that all makes it better. But I also think that sometimes we can get detached from the business problem and obsessive on the technical problem. When I know when I get into that space, that's when I'll start like doing like the enterprise function, mother factory thing, you know, or I'll, I'll figure out this way to, to generalize the problem into such a, an abstract way that any input could be handled. And the whole time I've still not solved the one input I needed to handle.

[00:22:38] Dave Adsit: Yeah. One of the things that makes me think about is the idea that code can be art or craft. Sometimes what we do is we slip from doing craft focused on solving a business problem or, you know, building something sellable that is creating value into art, which is creating value in a very different way, but may not actually ever solve a business problem. Right. I think that there's space for both, but I like to be intentional about when I'm writing code as art versus when I'm writing code as craft. And if it's code as craft, it should be clean and simple and implement a business function. And if it's code as art, it can be anything. There's some crazy code art things like the hundred language Ouroboros Quine or the international obfuscation. One of my favorites is the rockstar programming language, which is just hilarious and would be horrible to program in on a regular basis. If you're trying to deliver like an e-commerce website, but man, it's cool when you consider it from its perspective as an art form.

[00:23:58] Matt Baker: I think that there's this, this comment there, the perspective that you're viewing the code from, you know, if I'm sitting there and let's say I've gone out and, um, or maybe someone's hired me to write some code for them and I write some code for them. And when I present it to him, I show him, and I actually did this with one of my first bits of code. I was paid to write. I took the customer through the code and it was, uh, this lady that really was a very gracious and a DBA who was not gracious. I took him through the code line by line and, um, neither of them really knew how to code. And I said, and this does this, and this does this. And I'm talking a few hours of some BB script. Actually. And at the end of it, they were just like, okay, thank you. And I was super satisfied. I'm looking back. I'm like, wow, they were so kind to just like, let me sit and tell them about code that they did not care about at all. Right. We were talking from different perspectives. I was just stoked. I wrote something that worked.

[00:24:53] Dave Adsit: They wanted to know if I put this input in, do I get this output out? That's right. Demonstration over.

[00:25:02] Allan Stewart: Yeah. Well, that's a hard pill to swallow. This idea that code could be a liability because liabilities tend to be things that are bad. Objectively bad is like, you should get rid of all your liabilities, but in this case, and probably in a lot of cases, when we look at it in real life, it's like nobody would take on liabilities if they didn't need to. There's something going on that is enabled by that liability. And so we write code because there's things that we just can't do without code, but. Yeah. Divorcing yourself from that code enough to say this bit of code or how I wrote it this time isn't necessarily valuable in itself. So if code is a liability and you know, it's something that we need to keep in check and we need to keep our code bases small, then how do you tell what parts of code should be on the chopping block for deletion?

[00:25:56] Matt Baker: Oh, man, I bet. I know I would probably have a different answer for this depending on the day you ask me. So I'll just share today's answer. Someone said to me. And that's what I want to talk about. Code that is very stateful and is maybe doing a lot of integrations should be at the edge of your application. And the more it's not, the more it's intermingled with other parts of your application, the more that I want to delete that code. So my answer today is a code that mixes up a lot of state with a lot of logic because it's a lot of stuff to reason about in one function. And oftentimes it's very hard to test.

[00:26:28] Allan Stewart: Yeah. I agree with that. Yeah. I mentioned before the slam dunk one for me is dead. code. But then after that, there's these other ideas like duplicate code. Sometimes it can be hard to spot where the actual duplication is. And sometimes there are different parts of code that look similar, but aren't actually the same. And so you should not collapse them into one, but more often than not, it's very easy to just copy some hunk of code and put it over somewhere else instead of putting it into a shared location and reusing it. That's a place that I think that I remove code more often. In my general workflow, I think is where I do the most deleting of code. I mean, it's easy to want to just go into a code base and say, here, let me find some code, which code has angered me today. I will delete it in wrath, but that's, that's usually not the most effective. Like I find for me, I do the most, I do the most of my deleting on the code that I just wrote. I write a little bit of code and I'm trying to solve a problem. And I tend to do test driven development. So hopefully I've got tests that are backing me up and saying, yep, this is, this is working. This is passing. And so now I'm going to delete some of it because when I first started sitting down, looking at the problem, I thought that this was good. And then I learned later that it was not good. And so I go back and delete some lines and move some stuff around. And more often than not, it goes from, I needed 20, 30 lines to solve a problem to, okay, now I understand the problem and I can delete some code. So it's down,

[00:28:00] Matt Baker: to 10. It's making me think a little bit now about a time when I take on code that I intend to delete as a strategy. So I want to talk real quick about duplicate code in a way I use that to my advantage. I know I've done the global day of code retreat with both of you. Do either of you remember the TDD, like you mean it challenge? Yeah, for sure. All right. So I, what I, the, this is the way I remember it. Tell me if I got it wrong. I, the thing that stuck out to me most in that challenge was that you write the test right alongside the implementation, or maybe word of operations is you write the test and then you put the implementation in the test file. Yes. Okay. Yeah. So I do that when I code now, if, if the language allows me and I love it. So like when I'm coding and go, for instance, I'll, I'll create a, whatever underscore test.go file, I'll write the test and then I'll pass the test right in the file. I'll do that until I absolutely I should be able to parses all my parses in there. So I should be able to parses all parses in there. That should be easy to parses all parses in there. That should be easy to parses all parses in there. and you've got to back it out, right? And so I don't know if this is right, but definitely one thing I've been doing lately is allowing duplication to grow with purpose because I want to observe the patterns over time. And then at some point along the way, and I don't have any like science or math behind this, the total feeling at some point along the way, you just, it's time to delete it. There's some feature or some bug that comes along and you extract out and you start reducing that code. The whole time I know I'm going to delete it. And that's what's interesting to me right now. As I take it on, I recognize that I will delete you, but not yet because you're still valuable.

[00:30:05] Dave Adsit: Well, I think that that just speaks to a confidence around the ability to manipulate code. What would indicate to me that it's time to delete code had me thinking about the converse, which is when I was, this is going to date me a little bit, but when I used to carry around a zip drive with all the code I'd ever written on it because I didn't want to lose any of it because at that point it was all so precious to me because these were my hard one learning about how to solve this problem that literally nobody ever cares about after you turn in the assignment.

[00:30:39] Matt Baker: How big was the zip drive, Dave?

[00:30:41] Dave Adsit: So at first I had a zip 100 and then later I got a zip 250.

[00:30:47] Matt Baker: Now those are gigabytes, right?

[00:30:49] Dave Adsit: No, those would be megabytes. What? That exists?

[00:30:56] Allan Stewart: You only need like six, six floppy disks, three and a quarter floppies to fit your code on. Right.

[00:31:03] Dave Adsit: But at that point in my career, I don't even know if it was a career yet because I was still learning so much. It was so precious to me. I couldn't bring myself to part with any of it. Even though now get reset hard, I do that all day long. You know, I write some code. I don't like it. I revert it. I write a new test case. Then I learned that the test case didn't actually, it wasn't exactly right. So I just revert it and write a new one. You know, sometimes it's easier to write code from scratch than it is to fix what you've written that's bad. You know, everybody wants to work on a greenfield project because there's so many possibilities, right? And the very first thing that we do when we have a greenfield is we walk in and we make a huge mess. We burn all the grass down. We dick up all the rocks. And now we have a huge brown field and we're like, okay, this is a lot more comfortable in what I'm much more comfortable with. If you do that a couple of times, you just reset that field back to green state. And you're like, okay, I'm going to walk in there this time. This time I'm not going to blow torch all the grass. I'm just going to dig up these pieces. Being comfortable throwing away code that you've written means that you can go a lot faster and you can like try stuff.

[00:32:21] Matt Baker: I loved what you said about, okay, this looks more like what I'm used to. I'm going to take this greenfield project and dive bomb it into something. There we go. I've done it too, man. There's some sort of saying like what anyone can code in greenfield. I don't know. I don't know what the saying is, but it's something like that. Thinking of strategies you can use to delete more code more often. One that I like, and we talked about this a little bit last episode, but coding in the small. So Dave, I think in this strategy, get reset hard, or you're, whatever your version controls equivalent is your friend. You know, try a little bit. If it works, commit it. If it doesn't work, delete it. And one thing that I think we shy away from as an industry for some reason is delete it 20 times. You know, write that thing 20 times and delete it. That's what you need to do to learn the problem in order to express it, then do that. And so what I'm thinking about now is if you try and code in the big, it can oftentimes get hard to delete code because you'll, at least I have a tendency to build code, you know, I can't build a house of cards if I go a long time without committing and shipping, you know, but the more I code in the small, and I guess what I mean by code in the small is right. A little bit of code, make sure it passes all the tests and commit, and then do that again. The more I think you work like that, the more opportunities you have to delete code, you know, because it's, it's true. I believe that every time you try to write code to solve a problem, you learn a little bit more about the problem. And if you can just wipe the slate clean and take that information and try again, I think that's valuable. And Dave, it actually reminds me of the story you tell often about, what was that flower pots, clay pots that someone was building and the person, the people who iterate it always came out on top.

[00:34:08] Dave Adsit: Yeah, it was an experiment done by a pottery teacher. And I think with a sociologist about giving people a point for each pot that they make versus giving them 300 points for making the best pot of the semester. The people who spend the entire semester trying to make the best pot never did. The people who were like, I'm just going to get as many points as I can by making these pots over every day. I'm going to make three pots by the end of the semester. One of them also made the best pot of the semester because of the practice.

[00:34:38] Matt Baker: I love that story. And I would call that, I don't know, potting in the small, right? That feels like they're doing something in the small.

[00:34:45] Dave Adsit: Yeah. It doesn't matter how good this one is because I'm going to make two more today. And then you, you start to master that, those techniques, which is part of why, you know, the very first pot that you throw is precious to you. Just like my zip disc of terrible VB6 code that is sure to be unrecoverable by this point. Like even the best hard drive scientists probably couldn't pull that off of those old, old iOmega drives. So what you're saying, Matt, actually kind of reminds me of a recent blog post by Tim Ottinger over at Industrial Logic when he was talking about what about, what is it about micro commits? And he was talking about micro commits. And he was talking about how you can do these tiny little commits all day, and then you can revert to any point and try again, branch from there. But if you're doing like the one commit at the end of four days of work, you know, you are in trouble if you decided that you made a mistake a day ago, right? And so I think that, I think that there's something there that kind of plays well with what you're talking about of doing a bunch of things, doing the same thing over and over and over in small batches, small steps, and how you can actually find the right solution better that way than if you just try to implement the giant thing, the code and the big all at once.

[00:36:05] Allan Stewart: Yes, absolutely. The size of your scope is super important as you're looking at these things, right? So like at the beginning of this episode, we talked a little bit about how sometimes you just wanna just delete a whole bunch of code at once because it's so convoluted and terrible and you wanna replace it. Well, the thing about the Gilded Rose Kata is that it's already small. It's complicated because it's overwrought, but the problem space is really small. And so you can do it. The requirements doc is really small and you have to keep those small things if you wanna do deletes. It's almost like there's a spectrum between refactoring and rewriting. I think there are some times, we mentioned that one of my teams is facing this problem where they need to rewrite some code because salvaging the old code is just proving to be too, too problematic, too time intensive. But you still have to make sure that you're doing them in small pieces, right? They're not actually deleting the old code. They're building a new thing alongside. And if you try to build the whole system alongside, then you get that second system effect or uncle Bob would talk about the tiger team. It's like, oh, nobody wants to work on the project anymore. We're gonna go off and do the tiger team. And it's gonna be awesome because it's the green field and we'll deploy all of our modules immediately into it. So that turns the grass all brown. And we were there building the thing and you can never catch up to the old system if the old system is sufficiently large. But if it's small, you can catch it real fast. That's where the big players in industry fear the little upstart venture backed companies because they're coming in and they're small and they're tackling a small problem and they're agile, whatever that means. And they're getting things done because they don't have all of this entrenched inertia. And so that just, it reminds me, it's like, yeah, delete code, but be careful of the scope of what you're deleting. Sometimes it's better to refactor. If you're not careful, you can delete code in a bad way and be very sad.

[00:38:12] Matt Baker: Yeah. I, this space is near and dear to me. I think that a word of caution for everyone learning to program, when, when you start to feel like, when you start to feel the confidence that will propel you to delete code out of a code base without first verifying it, slow down. I know me personally, when I latch onto an idea, I tend to drive it as far as I can drive it until I find where it doesn't work anymore. And that's good. Sometimes it's not a good thing to do when, when, you know, you're being paid to work for someone else when it comes to deleting code, specifically, I'm, I'm beating around the bush. I'm going to tell a story. I once started up at a company that had a pretty bad legacy code base, very old, very, very hard to pivot and they were having a hard time keeping up with our customers and they're changing market. New competitors were coming in and they were looking for a change. So we had the tiger team, Dave, what you had been talking about. There was a new system that was being written and all the elite programmers were working on it and everyone else was on the piddly system that was paying everyone's bills. And I was also working on the new system and I went over to the piddly system and in a kind of a bout of frustration, I deleted some code that I thought was worthless and bad and not good. And so I just thought, you know, we don't need this code. It'll work this other way. And I made this little change, deleted all the code and shipped it. I didn't even test the thing. And it broke customers immediately. A support phone started ringing off the hook and the CEO came over to me real quick, let me know how pissed off he was and made sure that we reverted that change. And it was a real clean, it was a real clear lesson for me that, you know, don't go too cowboy. When you delete, make sure you've tested, make sure you know that the delete is sane or you might have that experience. And it wasn't a good one for me.

[00:39:59] Allan Stewart: Yeah. There's some code that you shouldn't delete. You have to be careful. There's some code that is hard to remove and maybe it needs deleting, but it can be difficult to do so. This makes me think about the corollary to needing to delete code is that you shouldn't write code when you shouldn't. And there's a couple of places where I think that this is important. One of them is don't use technology to solve people problems. It's super tempting. We want to do it all the time because people are complicated, much more complicated and much less deterministic than the software. And so if we can just put some technical systems into place, then finally we could control those humans and it never really works out very well. Sometimes you might come up with a good idea. It's like, oh yeah, we, we accidentally stumbled into a problem. But more often than not using technology when, when the underlying problem was a people problem is no good and it causes more pain than is necessary.

[00:40:59] Dave Adsit: To my knowledge, I've never hurt a computer's feelings, but the same cannot be true. The same is definitely not true about the humans I have worked with.

[00:41:11] Matt Baker: I know me sometimes I, uh, there's, there's a line or there's a point where I'm just fed up of talking with people at work. You know, I think we all get there where it's like, I can't talk about this anymore. I'm just going to go write some code. And I think that that sometimes is me trying to use technology to solve a people problem. Allan, to your point where I'm like, I, I don't know how to navigate this room anymore, but I know how to write this case statement that I need to write for this. So I'm, I'm going to go do that. Right. And, and I think I'm doing a good thing, but really I'm doing maybe the only thing I actually have control over and it's tempting, you know, but I'm, I'm avoiding maybe, uh, I, you could make the argument that I'm avoiding the root cause. Which is, you know, trying to figure out how to get the, the, the business or that part of the business anyway, moving in unison. And instead I'm trying to maybe paper over it with some, some code and a new feature.

[00:42:00] Allan Stewart: And sometimes you don't need any code. There's a story that I really like about pragmatic Dave Thomas. And he got called in sometime to make a like OCR mail system, mail sorting system of some kind. He looked at the problem for a little while and he asked a bunch of questions and he's like, well, what if you just use colored envelopes? Instead of writing any of this code. And that's what they did and saved the company a whole bunch of money. It was really effective. I think Neil Ford was related this on another podcast that I heard, but it's just this great example of, well, maybe just don't, maybe what you need isn't actually code. Uh, and I've seen this happen a lot of times, you know, you, you get into this situation where writing code is what you do and it's, it's your hammer. And so you're going to use that everywhere. Or maybe it's adjacent to some code. And so you think it's like, oh yeah, we've got this new business process and we're going to start writing some code to support the business process. This will be great. Like let's, let's encode all of these ideas into the system. But the problem is that sometimes that's not necessary and the business could have figured it out just fine without it being all coded up into the system. But now you've got all of that complexity there that weighs you down. And now if they decide, you know, actually we changed our minds, we're going to do it slightly differently. There's going to be a subtle variation and they will be always more flexible than your code is in being able to meet the business need.

[00:43:28] Dave Adsit: Well, and that just, that to me is a great opportunity to actually delete some code. I was thinking the same thing about the flexibility of code. Once you have encoded it, you have now locked the system until you're willing to change it. And so it's a great opportunity to delete some of the code that you've already coded. in a different way, or maybe just do something not involving code that solves the problem. So what are the hardest bits of code to delete?

[00:44:00] Matt Baker: Uh, yeah, that's a good question. Some of the immediate neurons I have is age. Older the code is, oftentimes the harder it is to delete. That's probably because the knowledge of the code dissipates over time. Right? Even if you had a team mob on the solution and all, let's say, five people had to do it, and all of a sudden, people knew the solution in and out. You know, over time that changes as people leave. Different teams, different companies, different projects. At some point, you know, everyone who wrote that code is gone. And so I think age is a factor, familiarity. Maybe age is just the proxy for familiarity. And definitely bigness is the other one that I think about right away. If I open a code base and find that hundreds of thousands of lines of it are written in stored procedures, I'm both simultaneously, like, jumping out of my skin to delete that code. And realizing that I, you know, I can't. And even getting my hands around it to test it is going to be a bear. So those are some immediate thoughts that come to mind.

[00:44:56] Dave Adsit: One of the things that I thought of was coupling. And you just kind of gave us the concrete example right there. You have the business logic in the database. Now your data storage and business logic are coupled together in a way that makes it very hard to change at all, let alone delete. The other one that I think of is the feature that's used by 2% of your user base. Man, it's expensive to maintain that feature and you would like to remove it. But it takes an act of Congress or possibly God to get approval to delete some of those features sometimes. Even if you've replaced the feature with a new feature that does the same or similar thing but better, you still sometimes can't get people to move over to the other way. And sometimes you just want to move their cheese. You're like, this isn't a profitable part of our business anymore. We have to drop this code and the support for it. But it can be very challenging.

[00:45:58] Allan Stewart: Even unused features sometimes are hard to get out because somebody believed in them at one point. And if somebody actually is using it, even if it's just, you know, it's that small percent of your customer base, it can be really hard to get rid of. Another place where I thought of that, it's hard to delete code. If there's not some test that describes the functionality or describes the business intent, like, well, what is the piece of value that comes from the feature? It's hard to delete that code because you don't know whether you're deleting something that was bringing value or not.

[00:46:34] Dave Adsit: Yeah, that kind of reminds me. You were talking a bit about, you know, the unused code earlier. And I was thinking static code analysis tools can help you find the unused code, whether you're using a static language or not. Yeah. the static analyzers will still be helpful in identifying that code. They'll also tell you whether the code is tested and how it's called and things like that. But sometimes it's just not enough. You have to get in there and write tests and try to take some of those safe refactorings to really understand what it's doing and how it's doing it before you know whether you can even delete it.

[00:47:12] Matt Baker: I agree. I think it's a game of inches oftentimes. You know, you can't. You just make lots of little moves until you're confident that you've captured what the function is doing in your tests. And I'm thinking of one refactoring now I did with a pairing partner. And I think it took it was with class and C sharp, maybe 120, 130 lines of code. And we spent a good five days on it, getting it under test. There was a lot of just a lot of stuff going on in there. And once we got it, it was OK. We wrote our tests and refactored it and deleted a little bit of it and went on our way. So what's sticking out to me. Is a it is a game of inches in that case and takes a long time. And you got to be patient and be testability. The degree to which I can test some code. Definitely a measurement of how confident I am to delete it.

[00:48:00] Dave Adsit: Another space where code is very challenging to remove is the code that you never should have written to begin with. For example, your own crypto or your own HTTP library. Your own queuing system. Or heaven forbid your own ORM. If you wake up some morning and think, I really want to write my own object relational mapper. Go for a hike. Think about the choices you've made that have led you here. And then pick one of the tens of thousands of existing ORMs that solves the problem. Because your business case is not ORM maintenance. And if you write an ORM, you will turn into the ORM maintenance. And you will be the maintenance guy for the rest of your time at that company. And that's not the fun job. The fun job is actually building code that actual users actually want to pay you for. Because it provides some value to them.

[00:48:59] Allan Stewart: It can be tough sometimes to figure out like where the balance is. Because, you know, I have regularly railed against frameworks. Because of the things that they do to me that I don't like. Or, you know, bumping my head up against the edge of the framework. Struggling to bend it to my will and make it do the thing that I want it to do. And so sometimes it's tempting to just say, oh, well, we should just write everything ourselves. Right? It's like that whole integrated vertical concept. Like we can own the whole stack. We can go and, you know, dig up some sand and make our own silicon. And like maybe, maybe if you're a really big company, if you're Apple, that's probably a good idea. But you're probably not. You're not Google. You're not Netflix. You're not Amazon. And so you got to figure out where to draw the line. This is my business problem. And this is where I'm going to write our code that makes sense. And then find those libraries or frameworks or tools that help you get away from that not invented here syndrome. Where you're reinventing every wheel. Starting with Grog's wheel that is kind of more of a square right out of a Far Side comic.

[00:50:08] Matt Baker: I'm thinking about ORMs. You know, it's very tempting. I almost think they're siren songs now. Some of the frameworks I see and some of the things you can build the quick and easy web application on. And I wish we had like a Twitter or something where people could tweet at us and tell us about their story adopting one of those. And I'm sure one of the worst stories they have about the night before a big release or something they needed to get done when the ORM or the web framework or whatever stopped working for them. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. That's all over. is that I just fall out of my chair and groan and get really dramatic until they drop it. Because I just can't, I hate that space. I hate when that shift from doing it for you to doing it to you happens. And if you built a big solution on top of it, you're kind of hosed at times.

[00:51:26] Dave Adsit: Yeah, it's really hard to make that transition.

[00:51:30] Allan Stewart: So I think one of the last areas to discuss about deleting code, and one of the things that makes it really hard to delete code sometimes, is the perception of self-worth that we get wrapped up around the code that we've done. And it can be hard to remember that the value that you're bringing to the company is not the lines of code you wrote, right? That's a Dilbert joke about the number of lines of code that you're gonna get paid for. What you're getting paid for is solving a problem and solving it well, doing it in a maintainable, flexible way so that your company can continue to move on to others.

[00:52:09] Dave Adsit: So as we start to wrap up today, one of the things that I wanna make sure that we say in a way that is crystal clear and sharp is that we are not our code. We are not our code. As software developers, our intrinsic worth is decoupled from the code that we produce. Ideally, the code we produce is continually improving, right? We should feel comfortable deleting, discarding, replacing, rewriting the code that we wrote yesterday or six months ago because I am not my code. I write code. Some of it's better than others. Sometimes I'm proud of it. But at the end of the day, the code that I wrote isn't who I am. So it doesn't hurt me to delete code because that's not deleting or, or diminishing me in any way. I think this is such an important thing that I have made people stand up at a software conference and repeat with me until I heard most of the room chanting repeatedly, I am not my code. I am not my code. I am not my code. Because I am a human and code is a thing I made for a purpose. And if it doesn't fit the purpose, I just get it. I get rid of it.

[00:53:37] Allan Stewart: Well said. With that, we'll close and recommend that all of you join a community of professionals by attending a software crafters group or meet up near you. Here in Utah, we have the Utah SC group at utahsc.org, which meets the first Wednesday of each month, currently virtually. And maybe we will delete some code with you there.