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: Own it. 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:46] 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 Kata recently. The way I chose to tackle Gilded Rose this time, which is a refactoring kata 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 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 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 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 the tests?"

[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 code? Code, the things that the code does for you, that the features that that come out of it, those are certainly valuable, but the code itself is that, does that have value? There's this interesting

[00:04:05] Matt Baker: question. I did a, uh, 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 are 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, you go to the other side of the room." And it was pretty evenly split. And then throughout the course of some conversations, 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. You know, if you can say something, if you can express it simply, we call that better. And, well, I call that better. And so, you know, 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 through the biased lens of what you were thinking when you wrote it. 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 of a kata. 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 Zuill 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. It'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 to it. 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 kata, you've anchored and now it provides at least inertia that directs, you know, what you can do with it going forward. It's a sneaky one too, because

[00:07:44] Matt Baker: it's not a building on a hill, right? You can't look at it and say, okay, if I want to manufacture manufacture cars instead of lollipops, I'm going to have to change my factory line, right? 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's, it can be difficult, you know, 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

[00:08:29] Dave Adsit: liability, you know. To that point, a few years back I sat with a group and we were doing a SWAT analysis. Don't, don't ask, but anyway, in the SWAT 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. And 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 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:33] Allan Stewart: seed. 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 that COBOL code that was written 40 years ago? Is that an asset?" I mean, maybe it depreciated all its value.

[00:09:55] Dave Adsit: That depends. 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. I know, Matt, you've done a bunch of VB.NET in the past. Don't tell anybody. Maybe that's No, I'm just kidding. Not the most valuable code anymore. I wrote ActionScript 3 with Flash. Now the browsers are getting rid of it. There's even a couple of 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's 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 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. We say, "once you've written it, it's good, right?" But is it? Do you have the latest patches on? 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.

[00:11:39] Matt Baker: I agree. One thing I like about this model is you're highlighting that even the most perfect code is subject to 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, Look, the world around you, 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, constantly making sure that your, you know, your code is tracking with the business strategy, 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, they add up to, I believe, a bit of an entropy that you do get exploited by if you're not

[00:13:11] Allan Stewart: careful. 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, you know, a zip compression on the whole thing." And, 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. We talk about how the software startup eats the software giant, unless 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 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. But 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 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. If you, if you rush into a market and you write a bunch of code really fast to try and find a fit and you don't have the money to, 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 a 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, is dead code. There's nothing worse than finding out that this complicated bit of code that you've been looking at and scratching your head on, and maybe you started refactoring it and rewriting pieces of it. It's like, "what is even going on here?" And it turns out it never gets called. It's never executed. It's not in the path of execution. And so it just adds confusion. It's just in the way. I've worked with people from time to time where there's been fear. 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. Them 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, like, build a monument to their own cleverness or their own ingenuity, right? Where it's like, "oh, these people are not going to see this generics method coming," or whatever, whatever, whatever metaprogramming, whatever, 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? Do, like, what does this function do?" It's, it's cool because it's a, like, a triple high order function that's composed of all this pureness and, and whatever. But, you know, I'll tell you, I don't know what it does. And I, 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, uh, as of late have been really, I've been writing a lot of Go and the last week or two. And so I think, um, that I'm sure that has a hand in it because of that 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 kinds 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 whether or not you can control your desire to show how smart you are in your code.

[00:20:43] 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, 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." 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. And it's interesting that I don't know how the conversation went, but I would wager through the course of the conversation at no point did they say, "and it solves this business problem super elegantly and it reduced the bottom line or and added to our bottom line by 20%," right? Like, oftentimes I've noticed that those parts of the the conversation are missing. And I believe that's the really only metric of whether or not the code is valuable. You know, you're there to solve a business problem to just 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 figure out this way to generalize the problem into such an abstract way that any input could be handled. And the whole time, I've still not solved the one input I needed

[00:22:36] Dave Adsit: to handle. 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 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. I think that there's space for both, but I like to be intentional about when I'm writing code as art versus when 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 100 language Ouroboros Quine or the International Obfuscated C Programming Competition. One of my favorites is the Rockstar programming language, 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

[00:23:55] Matt Baker: from its perspective as an art form. I think that there's this, this comment there, the, 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 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 this lady that really was very gracious and a DBA who was not gracious. I took them through the code line by line, and 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 VBScript actually. And at the end of it, they were just like, "okay, thank you." And I was super satisfied. And 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 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:55] 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 recently, "new is glue," and, 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 it's

[00:26:26] Allan Stewart: oftentimes it's very hard to test. Yeah, I agree with that. You know, 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. And 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 usually not the most effective. Like, I find for me, I do the most of my deleting on the code that I just wrote. I write a little bit of code and I try 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 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 to 10.

[00:28:02] Matt Baker: 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 Coderetreat with both of you. Do either of you remember the "TDD like you mean it" challenge?

[00:28:20] Dave Adsit: Mm-hmm. Yeah, for sure.

[00:28:22] Matt Baker: All right. So this is the way I remember it. Tell me if I got it wrong. 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.

[00:28:38] Dave Adsit: Yes. Okay.

[00:28:39] Matt Baker: Yeah. So I do that when I code now, if the language allows me. And I love it. So like when I'm coding in Go, for instance, I'll create a whatever underscore test.go 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 can no longer keep the functions in the test file for some reason, right? But the path to me getting there often involves multiple test files with multiple implementations of the same exact thing. Because I value more than reducing that duplication, I value keeping those things separate while I let patterns emerge, right? So it's a time where I say, "I'm not going to try and dedupe this right now because I want to see if it should really be deduped," right? Oftentimes you dedupe too early and combine all those functions into one. And then that, that rogue test case comes along, screws the whole pooch, 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 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, 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 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: Is so at first I had a Zip 100 and then later I get a Zip 250. Now those are gigabytes, right? No, those would be megabytes. What? That exists.

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

[00:31:02] Dave Adsit: But at that point in my career, I don't, I don't even know if it was a career yet, because I was 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, Git reset hard, I do that all day long. 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. Sometimes it's easier to write code from scratch than it is to fix what you've written that's bad. 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 and what I'm much more used to." If you do that a couple of times, you just 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. Let me take this greenfield project and dive bomb it." There we go. I've done it too, man. I, uh, there's some sort of saying like, what, uh, "anyone can code in greenfield." I, I don't know, I don't know what the saying is, but it's something like that. Uh, thinking of strategies you can use to delete more code more often, uh, 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, Git reset hard or your, uh, whatever your version controls equivalent is your friend. And, 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 and 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 a house of of cards if I go a long time without committing and shipping. But the more I code in the small, and I guess what I mean by code in the small is write 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. Because 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 David David actually reminds me of the story you tell often about, what was that, flower pots, clay pots that someone was building and the people who iterated all this came out on top.

[00:34:07] 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 are 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 start to master that, those techniques, which is part of why, the very first pot that you throw is precious to you, just like my Zip disk of terrible VB6 code that is sure to be unrecoverable by this point. 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 was talking about, what about, what is it 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 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 want to just delete a whole bunch of code at once because it's so convoluted and terrible and you want to 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 want to 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 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, side, 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 going to go off and do the tiger team. And it's going to be awesome because it's the green field, and we'll deploy all of our modules immediately into it." 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, you know, venture backed companies, because they're coming in and they're small and they're tackling a small problem and they're, you know, 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, this space is near and dear to me. I think that a word of caution for everyone learning to program, 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 you're being paid to work for someone else when it comes to deleting code specifically. 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 hard to pivot. And they were having a hard time keeping up with their customers and their changing market. New competitors were coming in and they were looking for a change. So 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. And 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. 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 can 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 accidentally stumbled into a good idea." But more often than not, using technology 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. 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 don't know how to navigate this room anymore, but but I know how to write this case statement that I need to write for this." So I'm going to go do that. 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 avoiding maybe, you could make the argument that I'm avoiding the root cause, which is, you know, trying to figure out how to get the business, or that part of the business anyway, moving in unison. And instead I'm trying to maybe paper over it with 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 it saved the company a whole bunch of money. It was really effective. I think Neal Ford has 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. And I've seen this happen a lot of times. You get into this situation where writing code is what you do and it's your hammer. And so you're going to use that everywhere. Or maybe it's adjacent to some code that you need to write. 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. 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:27] 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 written and maybe implement the feature in a different way, or maybe just do something not involving code that solves the problem. Them. So what are the hardest bits of code to delete?

[00:44:01] Matt Baker: 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. Even if you had a team mob on the solution and all, let's say, five people knew the solution in and out, over time that changes as people leave different teams, different companies, different projects. At some 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 at it to test it's going to be a bear. And some, those are some immediate thoughts 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 delete the other one that I think of is the feature that's used by two percent 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 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 that is untested. If there's not some test that describes the functionality or describes the business intent or, 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 a dynamic language or whatever. 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 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#, maybe 120, 130 lines of code, and we spent a good five days on it getting it under test. There was a lot of, uh, just a lot of stuff going on in there. And once we got it, it was okay, we, we wrote our tests and refactored it and deleted a little bit of it, went on our way. So what's sticking out to me is, um, A, it is a game of inches in that case and takes a long time, and you got to be patient. And B, 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. Stone. 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 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 where the balance is, because 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 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 Farside comic.

[00:50:08] Matt Baker: I'm thinking about ORMs. 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. And there's a subtle shift from doing something for you to doing something to you that occurs. And when it's 12 a.m. and you've got a 6 a.m. thing you gotta move on, you're gonna hate yourself for picking that framework because it doesn't, if you can't get to 100% sometimes, 99% doesn't matter, right? And I can't tell you the number of times ORMs specifically have gotten me into that trouble. I just, I won't use them at all anymore. Like, if someone on the team proposes it, 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 you, 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:29] 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 going to 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 other bigger and better challenges.

[00:52:08] Dave Adsit: So as we start to wrap up today, one of the things that I want to make sure that we say in a way that is crystal clear and sharp is that we are not our 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 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 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.