Grokking Simplicity

It was fun to be on Maintainable talking about maintainability and my book, Grokking Simplicity.

Transcript

[00:00:00] Robby Russell: Welcome to the Maintainable Software Podcast. We explore the art of improving existing software with seasoned practitioners who have helped organizations overcome the problems, often associated with technical debt and legacy code. I'm your host, Robbie Russell. On this episode, Eric Normand, who is a software engineer, trainer, and author of the book Rocking Simplicity.

[00:00:29] Eric joins us today from Madison, Wisconsin.

[00:00:41] Eric Normand, we're so glad to have you joining Summit Maintainable. Welcome.

[00:00:44] Eric Normand: Thanks. It's great to. So as you reflect

[00:00:47] Robby Russell: on your experience in the industry, what do you believe are a few common characteristics of, dare I say, well maintained

[00:00:53] Eric Normand: software, well maintained software. The first thing I think of is it's like a unicorn.

[00:00:59] Can't really find, find it in, in real life. Uh, but that's probably not fair. So I think that there's, like, you can correlate some things the size of the code. Correlates with its maintainability pretty well. So smaller code bases are easier to maintain and probably are better maintained. Um, I think the, the other thing is the, the team, right?

[00:01:30] So you, when you talk about the maintainability of it, it's always in context, like who is the one doing the maintenance? And if the team really understands the design of. And understands all the parts and how they're supposed to work together. They can continuously push the software towards that. It becomes like a shared understanding.

[00:01:55] And then there's challenges to that cuz the team might want to grow. And so now there's new people who don't understand it as well and they have to be onboarded or, or mentored into how the. It's supposed to be cuz you're never ever there. Right. But how it, how, where you're moving toward. So that's my, that's my answer.

[00:02:18] Robby Russell: You know, I think there's plenty of, plenty of people to talk about. It's easier to maintain smaller code bases. And I think I'm in the, the web software development industry myself, and so there's been a lot of. Ebb and flow of popularity of things like microservices. Like, well, if we break things down into smaller things, we can, that's a smaller unit of work and com, you know, and, and so we can have its own project, its own repository, its own, we understand what that's supposed to do.

[00:02:42] But then there's kind of like a, on a macro level, a different sort of complexity that can come up where you've got, you know, all these different pieces. And then so is the, the whole easier to. Or is it the, the smaller parts are

[00:02:53] Eric Normand: easier to maintain, but there's for sure, I've definitely experienced that on microservice projects where it's way more complicated than it could have been.

[00:03:03] One of the issues I think, and this is one I would probably come back to, uh, again, is habitability. Like we live in our code bases. You know, eight hours a day, like while you're at work. And so you have to find your way around and put stuff where it's comfortable for it to be. And like we, we forget the human side very often.

[00:03:25] We, we focus on the structure of it, uh, in terms of, you know, some kind of organizational hierarchy or something. But really we live there in our code and have to be able to find things and work with things. And I think. Microservices make that very hard. It creates this very hard boundary between two different services where you, it's hard to move code from one to the other.

[00:03:53] It's hard to break up a service into let, let's say, you know, where you could take a function call or a method and you know, a method or a function and break it into, that's an easy refactoring, but now you have. Endpoint on a service and you have to break it into, and now you, now the other side has to do two calls, but then there's error, possible errors between them and like, it just becomes a, uh, a much harder problem.

[00:04:26] Moving, you know, oh, this method should be not a call on another service. We call it so much. It should actually be part of this service and part, you know, just part of a, like a method call somewhere inside there, but like, how do you move that, that's a major refactoring. You got backwards compatibility issues with it.

[00:04:45] It's, it's a big. Yeah, I, I

[00:04:49] Robby Russell: can appreciate that. And one of the things, other thing you had mentioned there that I thought was fascinating was just having that conversation on where are we going with this code base. I usually come into projects that have been around for a while and there's these mess, different types of messes and things that their team's trying to figure out or they haven't dealt with someone in a long, in a long time.

[00:05:07] Or because, maybe because of the aboriginal person that did it was no longer there and everybody's been afraid to break something cuz they don't really fully comprehend what it's. But having conversations when you're onboarding new developers and like, where are we going with this piece of software is, do you think of that more in terms of where the product of the purpose, maybe there's part of that versus a distinction between where the new features that are coming up for this particular project versus where are we taking the architecture?

[00:05:34] Where are we taking the software, where. Where does the development team wanna take this going forward? And, and to keep, to maybe adapt to the, the future, the future things that are known and the future unknowns for

[00:05:45] Eric Normand: the software project. Right, right. Well, if, if the software has lived for a while, it probably has and been maintained for a while, like well maintained.

[00:05:58] Because if it's a total mess, if it's just a big ball of mud, all, all bets are off. Right? But let's assume it's been well maintained and now these new people are trying to maintain it. There, it, it's, it's all the stuff you talked about. It's, it's interrelated. There's no way to separate out like, well, we made this architecture decision completely in a vacuum.

[00:06:18] Now you made it because there was some external pressure that required it to happen. Maybe. You know, traffic spikes in certain parts of the year, and so you need this extra infrastructure that most of the time looks like it's over-engineered. Right? Or, uh, one, one source of it might have a source of volatility, like where we decided to have a plug-in structure in our application because we know we're.

[00:06:47] We're gonna have to take things in and put things out. So we have that kind of modularity there. And you might not see that happen until it happens and you're like, why is everything in plug-ins? We should just do, you know, straightforward, call this, call that, call that, no, you actually need plug-ins and it, it's extra complication, but it, you know, solves a whole bunch of problems that you, you, you won't see like in your first month.

[00:07:12] Right there, there's this paper. Software engineering as theory building. I think maybe it's software programming as theory building, but the idea is that the software is more than just the code that you write. That's just the instructions for the machine. But your team is also building a theory, like a practical set of tacit knowledge about what it's supposed to be and how it works.

[00:07:42] That if you don't pass that on, The teams that pick it up, that make a mess of it,

[00:07:49] Robby Russell: that's an accurate assessment of a lot of experiences that I've had. You know, in, in your consulting type work, getting brought in, do you, are you typically bringing, coming in as a, helping people better understand functional programming specifically?

[00:08:02] Or are you helping do things like help them navigate some refactoring or rethinking how they're modeling

[00:08:08] Eric Normand: things? So, I haven't done too much consulting. I have a, a few experiences. I did consult once where there was an app that they were building, and it was one programmer. This was a startup, and the programmer was new and was just making a lot of beginner mistakes and had built an app, but it was very buggy, and they asked me to come in and give my recommendations, and my recommendation was to rewrite it.

[00:08:41] It wasn't that. And to do it along, uh, functional lines. Uh, they were using React native just to get specific. They were doing stuff that was very hard to get right, which was, uh, to do like http calls within your components. To mutate state everywhere. And this was, I mean, this was years ago, six years ago.

[00:09:10] So one of the things I did was when we rewrote it, we still used React Native, but I used Redux and I, I rewrote it and then handed it to him and he started building new features on it. And then I would go behind. And like take out all the mutable state, make actions in ducks, like show him how to do it and he, you know, slowly learned how to do it.

[00:09:36] Robby Russell: One of the things I also wanted to make sure we touched on was your book Rocking Simplicity. So for those unfamiliar, you know, it's a, the learning guide for functional programming and thinking, you know, if you wouldn't mind, maybe could you provide a high level overview to what the book covers and, and whom?

[00:09:51] Do you believe this book might be best suited? And just for, for some context, my assumption is that a lot of the listeners are coming from web dev cuz it just happens to be my community mostly, and a lot of object oriented programming in, in that, in that space. So I'm curious

[00:10:07] Eric Normand: about that. Yeah. Okay. So the high level overview is I was always looking for a book for beginners for to teach functional program.

[00:10:21] And I couldn't find one that I could recommend to people. I've been doing functional programming a long time and people would always ask, well, what should I read to get started? And, you know, it would just, it would always be like, oh, well there's this Haskell book, but you gotta learn Haskell just to learn these, these things.

[00:10:38] And it like goes too deep. And so skip this chapter. You know, it'd be, it'd be too much. I had a million discussions with people about like, what's important in functional programming and what is functional programming? And eventually I found a few nuggets that I was like, this is the stuff that people don't know.

[00:10:57] And I wrote a blog post and then that turned into a conference talk, and then people started saying, well, this needs to be a book. And so I, I turned it into a book. So it's four people. Have some experience programming. It doesn't teach you to program or. If you're the person like me who needs a book to, to point someone at, right?

[00:11:25] You're, you, you've tried to find a book to teach functional programming and it takes it way, it, it starts functional programming way earlier than most books start. Most books will, uh, so they'll talk about pure functions, right? Functions without side effects. For like a paragraph, and then they move on and they get to some really complicated stuff.

[00:11:46] Well, we spend six chapters on pure functions and get people accustomed to working with them. Like what is, what are the consequences of this? How do you take existing code and refactor it so that it's got more pure functions? Why are we doing this? All that stuff. So it starts way earlier. This is the stuff that like I was looking for that no book ever explained.

[00:12:10] Like how do you. How do you actually refactor? How do you actually make work, get work done? If all you got is pure functions? And that's the thing, it's like, but you don't, there's you, you have to, you have to, uh, have stuff happen besides just calculating stuff. Okay, so I'll, I'll give a, a, the teaser of the first big idea in the book, which is that functional programmers discriminate between three things, actions, calculations, and.

[00:12:40] We did make that distinction. Actions are things that, uh, can affect the world or are affected by the world, uh, the outside world, whatever outside means. So whatever, you know, outside your scope, right? So actions are things like sending an email or reading the temperature from a sensor every time you do.

[00:13:01] It could fail, it could be different. So you have to be careful of when you call them and how many times you call 'em. You don't want to send the email too many times, right? And also when you check the temperature, it's going to give you a different answer each time, right? Calculations are computations from inputs to outputs.

[00:13:21] So it doesn't matter how many times you call it, you're gonna get the same answer every. So it's, you know, you use these all the time, like adding two numbers. You're always gonna get the same answer when you pass in the same two numbers. Uh, and then data. Data is just the, the inert stuff like strings and numbers and arrays that we have that become the inputs and outputs to our calculations and.

[00:13:48] Robby Russell: That's interesting. I know that some of the, you know, as I looked through a little bit of your book and appreciate all the, the nice illustrations of how people having conversations back and forth between them, you know, I was thinking about like the concept of a side effect and you, you brought up like maybe an example of like a sending an email and I'm trying to wrap my head around some of this in terms of like, all right, someone signs up for a user signs up for, um, prescription to some service and you want to validate that their email address.

[00:14:14] Like is a legit, so that you, you may send them an email and ask them to click a link to confirm that. Is that something that you see should be very much in, in the functional world? A like when you save that, then you should be able to send off that email and then how do you, where is that scenario where you worry about it happening a second time?

[00:14:32] Is it cuz they click the button multiple times or? I think I'm trying to understand what, is that something that happens that often or how is, how is, how is my brain not wrapping my head around how distinctly different that would be? Or is it that upon save, maybe there's something else watching if something gets saved and then that thing sends an email, but it's like maybe not directly in the code that the developer's looking at like save and then magically something happens after a save in some other area of the application.

[00:14:58] Eric Normand: So that's a really good, that's a really good question cuz it gets right at the heart. Why we we make this distinction. So if you're not careful in making this distinction, and I see code like this all the time, like you'll have a function called validate and save. You pass it in email address, and if it's valid, it saves it and returns true.

[00:15:23] And if it's not valid, doesn't save it and returns false. Now, if you're not careful with the naming, and maybe you just call it validate. Now it's not clear that it's doing something in the database, and so you might use it somewhere else. So those are the cases that often happen and you're like, well, I need to validate an email address, but I'm not trying to save this one.

[00:15:45] This is for some other workflow. And so, What do you do? Well, you should actually try to separate those out. Make validate one function, save another function. Don't try to do them both at the same time, in the same function. Separate them out. You can compose them later, right? You can do one after the other in another function.

[00:16:06] You can always do that, and so it's easy to see. Well, if I design it right, it's only gonna send it once, right? It's only gonna send the email one time. If we could design it right every time like that, uh, wouldn't be a problem. But that's not the world we live in. We often make these kinds of mistakes. And so the other thing I was the where I thought you were going, which is another interesting avenue, is if you map out a workflow, like a signup workflow, like they enter their user name.

[00:16:40] Uh, they click send, the server gets it, and you know, you, you just map it out. It all, it looks like it's all actions. Uh, the server puts it in the database, generates an id, you know, sends off an email to confirm their email address. Like it's all actions. But let's, let's talk about another scenario, and this is straight out of the book.

[00:17:01] Let's say you wanted to go grocery shopping. So you say, okay, I'm. Get in the car, drive to the store, go in the shop, buy my stuff, come out, drive back home, right? Oh, there's no ac, there's no calculations. It's just all actions and that, that's the, the way we see it often when we map it out, but there's tons of calculations in there.

[00:17:26] How do you know what to buy? Right? So you're going to look like, let's say you look in your fridge, well, you're gonna get some data, so you look in the fridge. That's an action because it depends on when you. Right. If you do it tomorrow, you might be outta milk, right? So you, you look in the fridge, you get some data like what's in there.

[00:17:47] You do some kind of mental calculation. What do I need versus what do I have? And then you generate sort of a shopping list from that. And that's, that's a calculation. It doesn't change the world. You can do it a hundred times, you're gonna get the same answer and it doesn't affect the world. So you have this shopping list, now you go to the store.

[00:18:05] Well, if you're driving, you're doing some kind of calculation about like, where I am, like where I need to turn, all that stuff. It's, it's very much. A calculation. Um, and so we often forget, and I try to, I try to emphasize this at, or use an illustration that. The calculations are the stuff going on, they're invisible cuz they're going on in our brains.

[00:18:30] Right? And that's the stuff that is invisible. And in the book we go through a lot of code where it looks like, well this is just, this is just how you would code it, right? But then we start pulling out the calculations like, oh look at this, this is a useful bit, uh, a little calculation that we could do.

[00:18:47] And it becomes reusable. Like calculating the tax on the, on the shopping cart doesn't have to be part. The same function. That's like sending it off to the, to the payment processor, right? You can have the CA tax be calculated as a pure function. Think even just expanding

[00:19:06] Robby Russell: on that, that specific example a little bit, and I actually was listening to you speak with another podcaster about this once, and they brought up like, well, what happens to your roommate?

[00:19:14] Someone else in your house, grab something outta the refrigerator when you're on your way to the store and it messes up your inventory locally. But we don't need to get into like, you know, the, the problems of concurrency, right. So yeah, that's just a distributed

[00:19:24] Eric Normand: system problem. Like what I'm

[00:19:27] Robby Russell: curious about, you know, I was thinking, have you found yourself been being able to see software engineers that are, say, working in an object-oriented programming language?

[00:19:36] Like, I typically work in Ruby, myself and. So we're doing a lot of things with following active record type patterns and, and we're working in an NBC framework. There's this interesting thing around like, well, we have all these benefits of having, I think what I think you would might call, like these side effects that happen like, oh, unsaved, like something, there'll be something that always will trigger something else somewhere else and it's like a couple steps away from where the developer's currently looking like, oh, and then, so there's some magic happening elsewhere.

[00:20:04] And that can be seen as a, a nice thing because we're like, well, it's great. It's up over here. We don't have to. Always remember to do that in this specific controller action so we don't get these really long methods to, that's like do this and then do that, and do this and do that. But I'm curious about like your take on that sort of approach.

[00:20:20] Do you feel like it's, that actually causes more confusion around be able to wrap your head around what's happening? Or do you think about things like. Whether or not that's violating some dry principle, if like you have multiple ways that say a product could be saved in different areas of the code base and then you always want something to go like double like updated inventory somewhere else or is your, do you see concerns around like the length of a method because it's doing a lot of these like procedural, like do this and then go fetch this information, do this, this, this, this, versus kind of passing some of that off to other areas of the application.

[00:20:56] Eric Normand: So I have a lot of thoughts there. The first one is that the amount of stuff happening is a real concern for understandability. Like your mind needs a small number of things to think about at once, and if these, the things you call magic are helping you separate out. You know, I don't have to worry about that.

[00:21:21] That's the magic right now. Right now it's magic. I, I should understand it, right, but right now I don't have to think about it. I'm just worried about this part, and then this other magic part will happen automatically. I mean, that sounds, that sounds great because. If you really can modularize it that way, like create a real boundary where you don't have to think about it, the trouble is it often is something you have to think about.

[00:21:48] And not only that, it's something that you have to work on both sides of at the same time. So, oh, I need to remember that I have to set this variable here because I'm gonna need to pick it up on the other side of this magic boundary that I shouldn't be thinking across. But I have to, cuz that's the only way to get it to work.

[00:22:10] Uh, I'm, I'm a big fan of like, super straightforward. Like, if you need to do 10 things in a row, just put those 10 things in one big method. Like I'm kind. I'm kind of that kind of programmer now, after many years of trying out like Rube Goldberg, put it in a queue and have something else, pick it up and like, you know, if there's 10 things to do in a row, like procedural code is like the right, it's the right shape of that code.

[00:22:41] Another thing I wanted to say was that the way I tried to define functional programming in the book, it can be done in any language. I've had a lot of people who've read the book who are working in a language like Java or Ruby or, or, or another mostly orient, uh, object-oriented language. Tell me that, like, this helped me debug something I was working on because it was too, too much for me to understand the code, but starting to separate out Okay.

[00:23:15] The calculations from the actions they were able to, to do that.

[00:23:22] Robby Russell: Yeah, thanks for kind of like walking into the, walking down that path a little bit for us and understanding like how your approach is. Like, it's not necessarily a bad thing to just be more explicit about what's happening in, in your appropriate order.

[00:23:34] Could you, could you tell us a little bit about what you consider our higher order functions? I saw that was referenced a few times and I'm not familiar with, uh, the terminology.

[00:23:43] Eric Normand: Yeah, sure. Uh, higher order function, the simple technical definition is a function. Takes another function as an argument or returns a function.

[00:23:56] You're probably familiar with these in JavaScript because there, that's like one of the things you have to do all the time is pass functions to other functions, either as a callback or you know, some, some other crazy thing you're doing with with the functions. And the cool thing about higher order function.

[00:24:17] And, and again, this is what I liked about them. I didn't want to get into, in the book, they let you abstract away some of the stuff in your language that's hard to abstract. One example is you have a four loop and a four loop. One of the problems with it is, The stuff bef, there's stuff before the, the actions that happen, like the cool stuff, that's the meat of the for loop, right?

[00:24:43] There's like a sandwich. The bread is the for-loop stuff and an open curly brace. And then at the end there's a closed curly brace and you can't. Like do normal refactorings on it where you say, oh, I'm gonna cut this method in half, like right down the middle of the sandwich and have one piece of bread on one side and one piece of bread on the other, you know, and the other function.

[00:25:06] You can't do that. What you have to do is turn the body into a function and now you can make a function that just does a for loop and takes another function and it's gonna call. Inside of that loop. That's, and you can do that with any of the syntax in your language, right? You can do it with an if statement.

[00:25:28] You can do it with any of the loops. Right. And the the cool thing is that now you don't have to be writing four loops all the time. And we're probably familiar already with like four each and map and what are they called in, in Ruby?

[00:25:45] Robby Russell: We use, we use Map and. Collect. I mean, there's

[00:25:48] Eric Normand: some things like that here.

[00:25:49] Collect. That's right. Yeah, yeah, yeah. And there's like select yes. For filter. Yeah. So these, these are, um, like kind of standardized ways of making for loops that now you don't have to worry about all the, the, the looping syntax anymore. One of

[00:26:08] Robby Russell: the things that, it's interesting, you know, so I, okay. I can appreciate how you're basically having that go off and iterate on that stuff rather than having that.

[00:26:16] There of code and so you can separate that out. Sometimes I find that to be interesting cuz the where, when that, when that scenario happens, especially if the, the stuff that's happening in the say that loop is only a few lines long, but then it's like, what is this thing doing? And does this actually easier for someone coming in to be like, okay, so what is that method being called?

[00:26:35] Because it's like, it looks. The, the line of code looks a little bit more complicated than being like, for every one of these, we're gonna do these few things and like you're still thinking like, where I am and the thing, so this is like an interesting readability thing sometimes if like, it feels like, oh, there's some weird thing because it's happening.

[00:26:51] And wondering how, like say junior developers coming into things like, well, what is this kind of magical looking line here you're actually doing? And you're like, well, it's actually just calling this other method every time it iterates through the collection of the things

[00:27:03] Eric Normand: that we're dealing. Yeah, and it, that is a, a concern, right?

[00:27:07] Because you can, you can learn the for loop once and use it in a million different ways, which is nice for like, it feels simple, right? I just learned one thing and look, it has these three parts, right? It has a little initialization, a little conditional that checks every time through, and then a little thing to do at the end.

[00:27:29] I mean, you can use it for a million things. The problem. Also, you can use it for a million different ways. Like, oh, instead of doing plus, plus, plus, I'm gonna do plus equals one, right? Or plus equals seven and I'm skipping seven. And like you don't see that when you're looking at a for loop all the time, or the conditional gets weird and like, when am I leaving the loop?

[00:27:50] And in my experience, it's much better to kind of standardize. Like you only need a. Different types of four loops, and you give them names like Map, filter, reduce, and then you just compose them up and you just build stuff out of those instead of writing these custom four loops every time.

[00:28:14] Hi there. We hope you're enjoying this week's episode of Maintainable. While you've been listening, has anyone crossed your mind who might be looking for help with their Ruby on Rails? Applic. Planet Argon, the producer of Maintainable podcast, would love to meet them. In fact, we've got a pretty sweet referral bonus program set up.

[00:28:33] If you send someone our way and they sign up for Planet Argon Services, we'll give them a $1,000 discount and your reward, we'll send you a thousand dollars. Just for connecting us to the right person. Sounds like a win-win for everyone. Head on over to planet argon.com/referrals for more info. That's planet argon.com/referrals.

[00:28:59] All right, let's get back to this week's episode.

[00:29:09] Robby Russell: So one of the, wanna quickly touch back on like, Something you had kind of alluded to was how you ended up writing a book in the first place, and you mentioned that you had a blog post and then you started giving some talks on it. People rest, you should make this a book. And you know, for those listening who are curious about taking that sort of path, you know, do you have, like, I might be thinking to themselves like, who am I to write or teach about these things?

[00:29:32] I, I know that you've been very passionate about functional program for a couple decades now and like more so than that, and. For those listening that are kinda like, well, I don't know that I'm qualified to, you know, write on or teach these topics. Do you have any advice to help demystify that? Or should they just actually just not bother?

[00:29:51] Eric Normand: Uh, no, you, you should bother if you're, if you're interested in writing a book, like you can't stop being interested in that. Uh, I think that for me, there was a long period of time when people were asking me, A book like, you know, publisher because I had a blog and publishers, they reach out sometimes and I would say like, I don't, I'm not ready.

[00:30:19] I don't think I have anything. And it wasn't until I had this blog post where I was like, this is something, I have something here. I've touched something new. I don't think anyone else is, is hitting right now. And then I gave that conference dog and it was well received and I was like, okay, yeah, there's some something that people might be interested in.

[00:30:42] And I think that that's the better way to go is to, to wait until something hits and you kind of can't, you can't give it up because you just feel so strongly for it. Writing a book, let me tell you, I started in 2018. About July, 2018, and I was, it wasn't published until April, 2021. This is more than three years, almost four.

[00:31:09] I rewrote the first part. I thought, oh, I'm a fast writer. I've been writing blogs for years. I can just write it out and it's just like gonna be 20 blog posts in a row, right? That's how I thought of it. Uh, I wrote several draft. In that first year I was working in 2018 and I threw them away. They, they are not in the book at all.

[00:31:35] It just took me that many drafts to figure out what is the approach I'm trying to take. So it's, it's harder than writing 20 blog posts in a rough, let's put it that way. Right.

[00:31:48] Robby Russell: I can, uh, attest to that as. Been a blogger early on in the Ruby Rails community. I was approached by multiple publishers and was signed a book deal, worked on a lot of it, but I learned that it was really difficult to work on a book about a new piece of technology, a new framework that's quickly evolving, where if you take a month or two off, you're seeing new features and functionality changing, and you're like this.

[00:32:15] Chaotically moving set of moving parts and needing to feel like I need to go redo everything in the first couple chapters over and over and over. And then it again, it just becomes one of the, so I have the experience of trying to write a book and then having to basically call quits a couple years into it being like, I cannot keep up and I can't do this.

[00:32:32] And it's one of my things I wish I had finished, but it was a trade off for other things that were, you know, interesting to me at the time as well, like running a business. Having said that, I can handle a podcast and I can handle these conversations, and that's my contribution at this point in time. But the book topic is like a thing that I keep revisiting once I'm like, oh, what if I should pick that back up again?

[00:32:51] Maybe someday. So another topic I wanted to dig into, you know, you had mentioned a rewrite and one of the things that I'm always speaking with, People on the podcast with and with the types of clients that we do is we're trying to help them avoid that. I'm like very much not on team rewrite unless under very, very specific conditions.

[00:33:09] Do you find yourself more often on the side of Team Rewrite or Team Refactor?

[00:33:13] Eric Normand: No, I'm on Team Refactor. Um, the trouble is that it, you, like even the refactoring usually doesn't happen. I'm also a fan of like refactor in a branch for understanding. You don't need to push that, just clean it up. Like maybe you've got, maybe you're onto something like this could be better, but maybe you're not.

[00:33:38] Like if you're, if you're at that point, like that's how I feel right now at my current engagement. I'm, there's like so much there where I feel like it could be better, but then when I try, I can't find a better way without you. Total. Totally. It's dissecting the thing. Um, and I'm just afraid of putting it back together.

[00:34:00] Robby Russell: I can understand that. Do you, do you encourage people that you work with to do that? A lot of that ex sort of experimental work and just to try out some ideas, but just be like, let's not merge this, but go off and try something. Or how do you even decide if there's multiple paths to try? How do you kind of wait those or rank

[00:34:19] Eric Normand: them?

[00:34:20] Um, I don't think there's a good way to rank them if you're not sure already. I, I like two approaches. One is do it on your own, just you don't have to answer to anybody cuz you're probably gonna throw it away. And two is do it as a workshop. Mob it, say we're gonna spend one hour a. On this module until we like it, and I've had a lot of good experience doing that.

[00:34:48] A lot of the resistance I've seen to refactoring is not like some philosophical resistance. It's more like, I don't know where to start. I don't, I don't think I'll ever finish. You know, why start if I'm not gonna finish, I'm not sure it'll be better. I don't understand how it works well, but if you can get everyone on a Zoom call, you know, as a remote team.

[00:35:13] So if you can get everyone mobbing this one file. People will start to, to see like, oh, it is possible. There is a lot in here that could change, and it doesn't all have to come from that one person, and the, the social energy motivates you to get through it. So I've had a lot of good luck with that. Like, let's just, it doesn't matter.

[00:35:34] Just pick a file. It inspires people to go refactor other places.

[00:35:41] Robby Russell: I think that's, that's, that's been an accurate portrayal of things that I've experienced as well, where if you can get those opportunities for people to get together and just talk through some stuff and like, how can we, like, let's, let's try to do some, let's try to improve this area of the code, even though it's not like a requirement coming from the product team.

[00:35:58] It's not, it's not on our cam band board necessarily, but it's something that, Let's just take this area and see what we can do with it and like the idea of just doing that in a separate branch. And you may or may not end up any better off than where you were or make any real significant changes. But I think it's good to kind of like encourage that as something to think about as a team so that they can consider that as a part of their normal workflow.

[00:36:23] And do you, there's also, one of the things I was curious about is if you have much experience. Keeping a backlog or working with your team, the people that you know you're coding with, to track things that are kind of technical, dead or just weird areas of the code, things you're feeling uncomfortable about and would like to revisit at some point.

[00:36:43] Do you have like an approach that you've found works well for the teams that you've been a part of?

[00:36:47] Eric Normand: Uh, no. I don't feel like I've ever been on a team where keeping a backlog. It is like, kind of like you're trying to keep a big to-do list of everything that needs clean up because without the forward momentum of cleaning up, you know that you're never gonna get through this list.

[00:37:08] So there's no point in keeping the list. Everyone knows where everything is. This is has always been my experience. If you're at the point where you're not doing any refactoring, You just gotta start somewhere and get the ball rolling. And I mean, another thing that refactoring gives people is that ownership, that feeling of like, this is where I live.

[00:37:29] I can move stuff. It's in the way, you know, I, I live in this house, this couch is in the wrong spot. I can't look out the window, or whatever you wanna do from your couch. I'm just gonna move it. If you get on a team and you join this team that has an existing living room with a couch and everyone's always sitting there and you're like, I really think it would be better over here.

[00:37:51] It's hard to do. So that's why we do it as a group like. We've moved the couch together, like, look out the window. Isn't this better? And if it's not and you move it back, whatever. But that ownership that like, yes, you're a member of the team too. You get to move stuff around. You get to change it. That's, that's super important.

[00:38:11] You can't have people afraid to change the code. That's like the definition of legacy. Wow.

[00:38:16] Robby Russell: I'm, I'm, you know, thinking through some past experiences myself, but anyway, when, when there's a newcomer to a team, you know, you mentioned like the, the backlog of like maybe that not being an ideal and there's always this.

[00:38:29] Interesting thing I find when I'm kind of observing this or someone might feel like, Hey, has anyone ever considered doing anything about this weird part of the code? And then they're like, we're like, yeah, we just not got to it. Or it's on the list somewhere. Or like, yeah, we know about that. It's weird. We don't know why it's like that because the person that did that is no longer here and we just haven't spent the time to do that.

[00:38:48] And I sometimes worry that, that when that those conversations happen, It can kind of like start to plant the seeds of like, it's not important to these other people on the team. So maybe it's not important for me to look at. So if you're a newcomer into this environment and you're like, I really think they, we should move that couch over there.

[00:39:05] But it seems like everybody's pretty settled on the couch being there, but then actually like nobody actually, that part of the team actually decided that the couch should be there. It's just where it is.

[00:39:13] Eric Normand: Yeah, for sure. I mean, I've, so I still feel pretty new in the code base that I'm working on now. And I found some stuff because I was working in this section of the code, I found some stuff, like trying to understand it.

[00:39:28] This doesn't make sense to me. Like it's not, it's like it's, it's not dead code, right? It's getting run, but it's like way more levels of abstraction than you really needed, you know, like at the end of the day, it just calculates the number. It's like always gonna calculate the number two. Like, can't we just put two in there?

[00:39:47] Or maybe have one where we like name, we give it a name, it's just a constant. And then put two, right? Like, can't we do that? And I bring it up and people are like, well yeah, cuz they're not in the code. They don't know. So their answer is always like, I'm not sure. Like I haven't, I'm, I think the answer is, You, you know, you gotta, you gotta use your judgment and, and take the risk.

[00:40:11] I know why I asked. I asked like, for in general, is this a team policy that we can just change stuff and when do we change stuff and like I'm trying to integrate into the team. Same thing. Like, is this a thing? Did y'all choose the couch location for a reason? I'm trying to understand because like, it's so clear as a newcomer that it should be over there.

[00:40:34] Like that stuff is hard and there's two problems. One is there could be a really good reason why the couch is there. Nobody remembers, or someone does remember and they don't speak up, you know? But then also it could just be that no one is, no one cares where the couch is, and you have some little insight that they don't have because they've been looking at the couch being there for so, And I think that the number one thing is that the, that couch is mobile, whether it's in this spot or that spot, it can move.

[00:41:08] And that is the breakthrough that people need to have. It's like, oh, I've never, I've worked in this code, this section of the code for three years, and I've never seen somebody just go in and take a, you know, add a new function. Like we were just treating it like, don't touch it, but you went in there and you did it, and you, it still works.

[00:41:26] Like, oh, wow, I didn't think we could do that. I didn't think we could move the.

[00:41:31] Robby Russell: So if you're listening and you've recently joined a team and you're thinking about these other things, you know, you can just tell people that Eric said it was okay to move the couch, cuz you can always move it back or you can always move it somewhere else.

[00:41:43] And I think as people join. A team, or they've been part of a team for a while, but like if, say, if you're joining a new team and you are trying to understand the dynamics of them and like you brought up, like what are your policies on? Like, can I just change things? So I'm hoping most teams would say, oh yeah, of course.

[00:41:58] Like that's what we want. But do they actually do that? Do they, can you gimme examples of how you're doing that? And like, but I think you can have those conversations early on and start to. Is there a worry about needing to get permission ahead of time or should you just be like, I'm gonna start making changes?

[00:42:10] Because that's what the company hopefully hired you to do, is what is to be a good steward of the code base and think about the long term maintainability of it and make changes and, and not just follow just the same patterns that your team has historically done. Cuz it's not necessarily that they've done it better, they were just working within the conditions at the time.

[00:42:30] Eric Normand: And the, and it's a hard question to ask, it's a subtle question that I don't think I was asking proper. I wasn't asking, tell me the four rules that I can follow and turn my brain off so that I know when to, when to move code, when not I was asking for like permission to use my brain. Right? So people might be hesitant to gimme permission or to, to answer like, what's the policy when they don't trust me?

[00:43:00] I'm a new to the. And like they don't know what I'm gonna do, but like that's what, that's why you hired, that's why we have version control. That's why we have tests. Like all this stuff is so that a newcomer, I mean, and we're all newcomers at some point, right? E, even if you are old, but you haven't been in that piece of the code for a while, you're a newcomer again, like all of that is so to protect us.

[00:43:25] Moving the couch to the spot on the floor where it's gonna fall through. Right.

[00:43:36] Robby Russell: We'll be back with our interview with Eric in just a moment. Hi, it's me, Robbie. I just wanna take a quick moment to say thank you for making time to listen to alof or Podcast. If you're finding these conversations valuable, please consider sharing a link amongst your peers and our writing review on Apple Podcasts to help spread the word.

[00:43:51] Also, do you know someone that I should be interviewing? UN. They think would have a good story to tell. Shoot me an email to Robbie with a Y at Maintainable fm. And now let's get back to our interview with Eric Normand.

[00:44:13] Is there a non-software, non-technical book that you find yourself reckoning mending to peers on a regular basis?

[00:44:20] Eric Normand: Non-software non-tech? I like this book called, it's kind of technical, so I'm, I'm hesitant to say it. It's called Thoughts on the Synthesis of Form. Yeah, I'm looking over at my shelf to see if that's the right title.

[00:44:37] It's by Christopher Alexander. I also like the Timeless Way of building, and I'll tell you why. I like timeless way of building. It's about architecture. But the whole first part of the book, every time I read it, it reminds me that there is a subtler side of, of any technical work that I, I often ignore. Uh, the, we, it's so easy to get caught up in the details of getting something working and like making sure it's efficient and, you know, whatever your constraints are, and the idea that like, well, this is serving people and it, I have to live in the code like that subtler side.

[00:45:27] I, I often forget, and this book, every time. Pick it up. I'll read a couple pages and I'm like, oh yeah, like this. This feeling of like, there's a whole system that this thing is part of that I have to be aware of while I'm programming. Like you have to sup, you have to focus when you're engineering. Like let me get this thing working right, but like to remind yourself that there's a bigger thing.

[00:45:52] Great.

[00:45:52] Robby Russell: I had not heard of that one. I'm gonna check that out myself and include links to that in the show notes for everybody. Where can listeners best follow your thoughts on software development and learn more about

[00:46:03] Eric Normand: you online? Right. The best way I'm most active on my podcast right now, so if you go to EricNormand.me, uh, the, you can find links to my soft, my podcast, uh, where I'm working out ideas for my new book, and also you can find my writing and, and stuff on there, too.

[00:46:23] Robby Russell: Excellent. Oh, definitely include links to that for everybody in the show notes. I noticed, uh, listening to a couple of episodes, they're kind of short form talking about a concept like five, 10 minute long episodes and stuff like that. So I think that's, it was very interesting to be able to go through and listen to a few things there.

[00:46:36] And I'm like, okay, this is, this is, I like these kind of bite-sized pieces and so I appreciate that.

[00:46:40] Eric Normand: Yeah, and it's definitely me working through ideas. Like, it, it like, don't, don't think, oh, Eric believes this. Like, no, I was just thinking that that day and like trying to figure out how to explain it and so yeah.

[00:46:55] Robby Russell: Well, thanks for your, thanks for your contributions there. I think that's very helpful. Well, it's been such a delight having you join us on Maintainable. Eric, thank you so much for stopping by the talk

[00:47:02] shop.

[00:47:03] Eric Normand: Thanks for having me. It was a blast.