The episode opens with Mike sharing two stories that set up a theme: context beats dogma. First, a bike rack bolt snaps seven miles from home with his toddler on board; he “hacks” a fix using a strap to limp back safely—imperfect but right for the moment. Second, he yells to stop that same child from leaning over a railing—normally a “don’t,” but justified to prevent harm. Bridging to software, Mike argues that sometimes you should break best practices: a hard-coded, partner-specific access control once shipped as a pragmatic stopgap, worked for years, and only now is being replaced with a proper, general solution.

From there, the group explores when and why “best” practices stop being best. Dave frames it as “there’s always a best move”—for this context. Will and Kyle note performance work routinely trades readability and safety for speed; measurement is essential, or all you’ve done is make code harder to read. They contrast language and ecosystem philosophies (Python’s “one right way,” Ruby’s malleability, Java’s explicit structure), agree that humans are the expensive resource (optimize for mental load and boring, readable code), and acknowledge domains (firmware, game engines) where constraints force “ugly” but necessary code. The team also debates two coexisting feature-control systems—slow but self-contained env-based flags vs. instant, granular runtime flags—concluding both are needed because different roles value different trade-offs.

They close on practical guardrails: prototype fast, even “sloppy,” to learn and validate; refactor after you’re green. Use YAGNI—don’t solve tomorrow’s problems today—and be kind to “future you.” Keep a backlog of intentional hacks, prioritize cleanup time, and recognize that some code paths matter far more than others (optimize the hot ones; duplicate templates when sharing adds needless complexity). Break rules deliberately in sandboxes to learn (e.g., Juice Shop, OWASP exercises), but in production favor simplicity: make it easy and explicit unless you’re forced not to—then measure, mitigate, and circle back to clean it up.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I will be hosting again today. With me, I've got Jordan, Will Archer. We've got Dave.

DAVE: Howdy, howdy.

MIKE: And Justin, and Kyle.

And, as usual, I'm going to tell a story [chuckles]. Actually, I've got a handful of them here. I'm not sure if I can share all of them, but I think I want to introduce the story by first telling a story about cycling.

The great Sandi Metz shares a lot of good stuff. She talks about cycling all the time. I can do lots of cycling stuff, right? So, I'm going to tell a cycling story. So, I was riding with my kids, and I had my youngest in a bike seat sitting on a rack that was over my back tire. And he was getting a little big probably for it [chuckles], but it worked fine. I could do it.

What I didn't know is that maybe getting that top-heavy on the rack I had was putting a lot of stress on the bolts that were holding it up. And I was doing a loop, and it was, like, seven miles from home, luckily, not that far, but seven miles from home. And the bolt sheared off that's holding the rack up [chuckles]. Not a great thing, you know [chuckles]?

DAVE: With him in the seat?

MIKE: With him in the seat. That’s right.

DAVE: Because of the weight on the bolts. Yeah. Okay. Yeah.

MIKE: Weight on the bolts. And so, the rack drops on the tire, suddenly stopped. I’m going up a hill when this happened, you know, rocking back and forth because I'm going up the hill, of course, putting the stress on the bolts. I suddenly stop. You're not moving anymore, right? Now what [chuckles]? Seven miles from home. I can't really push the bike because now the rack's sitting in it. I can't take him off the bike and make him walk seven miles. He's, like, three years old [laughs], right? That's not going to happen. I also had a tether to pull the other two kids.

So, it was a bad situation. What do I do now? No one was at home to come pick us up. I could have called, like, an Uber or something, but what do you do? "Uber driver, can you come put three bicycles and a car seat [chuckles]?" There was no good way out of the situation.

DAVE: You got two kids on a tether. Dog sled.

MIKE: Dog sled [laughs]? Not going there [laughs].

DAVE: Fair.

MIKE: After some careful analysis, I got an idea, and I had a strap that I use for strapping stuff to the frame, like a water bottle. And I connected the strap to my bike seat, to the rails on the bike seat, to hold it up, and wrapped it around one side of the rack and pulled it really tight. So, it was just hanging from the strap by my seat.

I found that if I sat down on my seat…and I was standing up to peddle, right? I went as gently as I could. It didn't hit my spokes very often [laughs]. I got back on, and I rode seven miles home that way. And I made it. And I took off the tethers. The other kids, they rode independently [laughs]. They can make it seven miles. It was fine. So, we did it. We made it home. And that was not the purpose that those straps were made for [laughs]. There was nothing in there that was serving the correct purpose, but we got home.

Okay. So, that was story number one. I think it's a good one [laughs]. So, a tiny little story. You shouldn't yell at your kids, right? I think most people would say, “No, don't yell at children.” That accomplishes nothing.

Yesterday, my youngest, again, he is a common thread in this set of stories, was upstairs, and he leans over the railing, just jumps up, like, jumps up on the railing and starts leaning way over. And I yelled because [laughs] I was horrified. “You need to get down. You're going to fall off and something terrible is going to happen.” And I don't regret that.

He didn't like it. I didn't like it. There was some hugging and talking and making sure he was okay afterward. But, you know, I broke the rules, and I did something that normally I would not be proud of. And I made him sad, and I don't feel happy about that. But I was scared, and I wanted him to live. I didn't want anything, you know, any of the horrible consequences that could have come from this to happen. So, I said something, you know, I did not do what I would say that any parent should do. In this situation, those rules didn't apply [chuckles]. You know, you do what you can to save somebody.

So, we talk about software, right? I'm talking about outside of software. Let's talk about software. Sometimes you should not follow best practices. Sometimes you need to strap something on, and that's the right thing to do. Go ahead.

JUSTIN: I mean, if you're going to apply that back to your bicycle, I think you should still be riding with your kid hanging off that strap today [laughter]. That's really what happens [laughter].

MIKE: Well, okay, so, I've got a software story. Years ago, literally years ago…I don't think I'm saying anything that's exposing anything horrible [laughs].

There was a partner who had a feature request that was just for them, where they just needed certain employees to have access to a certain feature, and we didn't have a framework to make that happen. In this context, we just didn't need it, so there was no need to build it out. Nobody else was requesting it. And to build the framework to make this happen so that it would be generally applicable across all the users would take months. And the customer needed it, like, already, right? And there was no way that's going to happen.

So, we put in a hack. We just hard-coded the users that got access to the feature. If you're one of these users, you get access. We didn't make it too terrible because it was configurable, and you could set up in your environment. It wasn't, like, in-line in the code, but, yeah, it was a hack. And the customer was happy. Didn't build the feature, and years later, it still works [laughs], you know, the straps holding it on. And, in this case, it wasn't that important, right? It was a pragmatic fix to a nasty problem, and it was kind of a nasty fix to the problem, but it worked. Not too many people…there are actually a few other people who have requested the same feature, so it's grown.

There is a plan to mitigate this. It's actually probably going to be happening in the next quarter. But after years of doing good work, this hack is finally going to be retired. Man, it did its job, and I don't regret it [laughs]. I'm actually kind of proud that we solved this problem, and it worked, and nothing was harmed. Sometimes it's the right thing to do, and a brilliant hack, I think, deserves some respect. Oh, I've got some thoughts about some rules about when to break the rules. Well, I'm curious what you all's thoughts are. I threw some stories out there to seed some discussion.

DAVE: There's a phrase that I've trotted out in front of most of the people on the call at some point, if we've been working together, which is there's a fantastic book from years and years ago called “Bobby Fischer Teaches Chess,” Chess Grand Champion from the ‘70s. One of the lines that I remember from Bobby's book is he says, “There's always a best move. You might not have any good moves, but there's always a best move.”

And this is kind of what I see as that being, right? Is it OSHA-certified [chuckles] to strap a rack and then hang a child from it that you're actually related to and theoretically care about [laughter]? Of course not. But you're seven miles from home, right? That's probably the best answer, or at least one of the ones that qualify for that. If you'd had somebody with a pickup truck nearby, that would have been the better option, and it's fine.

The thing that I get thinking of is when we say best practices, I hear Best with a capital B, or Practices with a capital P. And I see it engraved on a leather-bound book that looks suspiciously like scripture.

MIKE: [laughs]

DAVE: And all you have to do is see somebody misapply scripture in the real world to realize, okay, yeah, it's called best practices because that's the name on the book. The gotcha to a best practice is the context. Is it the best practice for this specific moment? Usually, what a best practice is, is absent other context, this is a really good way to do it, and we probably should. And we've given thought to these things that you may not have considered, like security or, you know, integrity, or something like this.

And just jamming in a quick user ID check, of course, that's going to be rife with problems, so it's not a best practice. But I argue that having cash flow come in is absolutely the best practice, 9 times out of 10. And getting it working, getting it shipped, minimum viable product. And then if nobody ever used that thing, you throw it away at some point, and if somebody does and it gets really popular, you refactor it. Or, like Justin said, you ship straps with every bicycle and no bolts, because that's just how we do it now [laughter].

WILL: I mean, I'd say, like, you know, from a software engineering context, I don't know, I can't think of a single performance optimization that isn't deliberately contrary to all software engineering best practices. It's going to make it more fragile, more complicated, more state, harder to read, harder to update, everything. Everything you do to make things fast, right, is going to make it worse, right? So, is it worse or is it better? It's faster, and it's harder to deal with, right, and that's --

KYLE: Actually, what I was going to bring up, too, is that's where I've seen a lot of pitfalls in, quote, unquote, like, "best practices for coding," is when you want to get performance out of your system. They don't tend to go hand in hand.

WILL: Nope, cross purposes, every time. I would say, like, 100% of the time, they go cross purposes. I can't think of a violation of that. Sometimes you get performance stuff via the platform or via the language or via anything like that. But if you've ever sort of followed the internal turmoil of an open-source project that's really trying to get their performance game in order, let me assure you that the tears are there. Just because they're not yours, they [inaudible 11:34]. Going fast hurts, you know. Most racecar engines, you know, you couldn't even get started if you weren't a serious mechanic. That's how it goes.

DAVE: I used to own a Jeep Wrangler, and we called it, it feels like driving a basketball because the suspension on it is built for off-road, not for the highway. The thing you mentioned about optimization, this isn't that quote, but it's absolutely based…treats your statement as bedrock. The thing that I will tell people is you have to measure. When you do performance enhancement, you have to measure. And here's the quote that shows the bedrock of what you just said. Because if you don't measure, the only thing you know for sure is you made the code harder to read, and that is straight it, yeah.

MIKE: So, there are multiple different dimensions of good, and they're sometimes at odds with each other. And it's very easy for us to get fixated on one of them and to the detriment of things that we should be caring more about.

WILL: Unless forced otherwise. Unless I'm forced otherwise, I will always, always optimize for what's the least amount of thinking that I can do to get this project done? That's my North Star. What's the least amount of thinking? I just do it the easy way, like, mentally, mentally load. I optimize for my mental load, unless I'm forced to do some other thing. Going back and fixing bugs, high mental load. What did past Will do? That asshole? Oh my God. I don't want to think about him. I want it done. You know what I mean [chuckles]?

And so, that's it. I don't want to think about it. And if I do have to think about it, I don't want a migraine pill [laughter] reading through whatever the hell I did. And so, that's my North Star. Make it easy. Make it easy. Just finish it one time. Make it boring. Make it clean. Make it stable. And then if I'm making so much money that people will, like, back a truck up to my house so that I have to make it fast, fine.

MIKE: [laughs]

DAVE: Deciding in advance what the best criteria is going to be, when those criteria are kind of...how do you tell them apart, right? I rushed into Python from Perl because...I said in the pre-call Perl is a write-only language. I love Perl. I've spent a lot of time down in it. I've blessed a hash or two. If you know what Perl is, that tells you about where I was. I've never met Larry Wall, but that was next. I love Perl, but it's very, very cryptic. And Python comes along, and it's all about make it clean; make it readable. And I'm like, yeah, let's do that.

And Python has this rule, which is there's one right way to do it. And the supporting quote that they will use is…because you come back and you say, "Well, but if I want to do a map reduce, that should be a slick inline because I'm just doing it." And they're like, "No, no, no, no. You need to have the for loop. You need to have the..." I mean, they have comprehensions now. I'm old. This was a long time ago. But Python, you had to have the colon, and the indent, and da-da-da. And if you want to do it twice, you had to have another one. And their argument that they would say is the special case is not special enough to warrant a special case.

What they're saying is if you can look at the structure and you know what the structure is, you can infer meaning from the structure, then that's going to increase your understanding. It's going to reduce the mental load. And you then put your...the difficult portion of your algorithm is in the parts of that structure where you would expect to go look for.

And after I'd been in Python for five or six years, I started realizing there's times when the special case is really, really more convenient. Like, doing it the one right way is the worst way possible to do it. And all these promised features of, "Well, it's going to be more readable," no, it isn't. None of that actually paid off. It turned into scripture for me. And as soon as it became dogmatic, it started to really leave a bad taste in my mouth.

This is why you've heard me talk about coding, where I'll be like, I like to program in a language where a big idea should take up a big space on the page. But a small idea should be compressible down to something very, very small. And I have written a 300-character line in C with a comment in front of it that said, "Don't touch this unless you know what it means. This is a big, hairy, scary…" And, literally, it was vector math, so I didn't want people touching it.

It was literally, if you touch this, the motorcycles will fall over, because I'm literally applying a torque on the Z-axis of this motorcycle to keep…it was a racing game for when I worked at Acclaim. And I wanted a very dense, very packed, very...I wanted the line to scare you, not because you needed to be afraid of it, but because I needed you to respect it.

And when we did actually make a change to that line, it was two of us at a whiteboard, and we spent three hours unpacking the math, unwinding it to deoptimize it, to make it easier to read and understand. We made the change we needed. And we packed it back up because all it was, at the level of the method we were looking at, it was just one thing that was, make sure the bikes don't fall over. That's all it was. It was just give me a little bit of a torque impulse in the rotational axis. And I guess that's what torque means.

But we wanted that compressed down to be something really, really hard. Would I write production code like that all the time? No, not unless that was the...I wouldn't write the whole method that way. This was a 2,000-line physics method, and that was one teeny, tiny piece of it. And I wanted it to be one teeny, tiny piece. And if we had unrolled it, it would have been half the function for one-tenth of the functionality.

And unfortunately, optimization...this was on a PlayStation. I couldn't make a function call because I did not have the budget to push things onto the stack, make it jump, and do it over there. So, I literally couldn't extract it out of the source code [laughter]. It had to be packed into that spot.

WILL: Oh, I remember that, yap. I can't allocate memory in this loop. This loop, I cannot allocate memory and maintain the performance guarantees that I need to keep my frame rate up or my bit rate up, or whatever.

DAVE: Mm-hmm.

WILL: Mm-hmm. Mm-hmm. Yeah, you're going to see nasty work in situations like that, real, real ugly work. And you don't do it unless you have to.

DAVE: I toured in...my grandfather was an oil man, and I remember riding in the truck with him as a little kid and looking at the pump jacks. And I remember at one point looking at this machine, and it's hydraulic cylinders 12 inches in diameter, and it smelled of sulfur and just awful. It was tar everywhere. It was filthy. It was awful. It was a miserable experience. And me as a six-year-old kid going, "This is gross. Can we just not be here, please?" And my grandfather says, "Look at how beautiful that is." And I'm like, "What?" And he was basically saying, this is a big machine that does a big job. It's important, and it's a messy job. It's shoveling muck, almost literal muck, right?

WILL: It’s literally shoveling muck.

DAVE: It's pumping sticky, gross crap out of the ground so that we can have civilization. And that big, gross, tar-covered, sulfur-smelling machine was doing exactly what...it was supposed to be covered in tar and smelling like sulfur. That's what it was. That was its point.

WILL: Yeah, man.

DAVE: These analogies are getting weird. I like it.

WILL: Yeah. Well, no, I mean, I think that's, I mean, here is specifically, like, this is one of the grievances that I've always had with Ruby in particular. And [inaudible 19:16], I mean, I love the flexibility and the dynamism of the Ruby language, but I feel like there's a foundational trade-off. It's a foundational strategic error about human nature that Ruby programmers got kind of wrong.

And as much as I hate to say it, I feel like despite being in my soul a Ruby programmer and I really love it, but the language itself is completely malleable. It can do whatever you want. You can write whatever domain [inaudible 19:46] language that comes into your mind, and you can make anything happen, and people frequently do, right? Which is a wonderful thing because you can, like, express these beautiful thoughts very succinctly, and things can just flow. And you can run the mother of all demos where you just, like, bam. You just kind of log up in real time right in front of you because all these things magically unfold, which is a beautiful thing.

But versus, I mean, the counter-example of that is, like, just nasty, crusty, fusty old Java, right, where everything, like, where's this class? And I'm like, well, I'd tell you. I'll give you a hint. It is laid out right in the class. There it is, boom, boom, boom, boom, boom, directly structured. I could follow that chain right to the file, and I know exactly where the hell it is, and I know exactly what it does, and I know what it will do, and what it won't do, what it expects, and, like, et cetera.

But it's, like, big, and it's crusty, and fusty, and, like, ugh. But it's all laid out explicitly. And, like, the problem that I think where, like, I was like, okay, well, why is Ruby such a niche language? I’m like, no, well, it's kind of because of this. Because if it's just Voodoo and it happens just magically, right, well, how do you know the incantations, the magic spell? You know, where's the grimoire, you know, that I'm going to use to summon it up this web page? What's in the documentation? And what do programmers not really get right? Yeah.

DAVE: The fact that they don't ever document, let alone document well.

WILL: Nothing. Yeah, and so, like, you get the sort of, like, graveyard effect, right, where, like, the grand wizards, you know, they know everything, you know [laughter]. But, like, but if you're not the elite Dumbledore-level sorcerer, you can find yourself stalling in the dark for a very long time trying to find, like, where did this stuff go?

And, you know, Rails starts to mitigate it because, like, they're like, hey, just put it in the right place, okay? But that's, like, you hope you put it in the right place [laughter]. You hope the other guy put it in the right place, you know? But maybe they were busy. Maybe it was a Friday afternoon, you know? Maybe, like, somebody put it in, and they're just like, ah, just put this one next to the other one; it'll be fine, you know? Anyway, it's a little bit of a tangent. But, yeah, and it's just, like, I'm just trying to be as lazy as I can get away with and still keep my job.

MIKE: So, you're saying, building on what you said before, making things explicit, boring, easy to read should be the goal in almost all cases.

WILL: Just keep it easy, man. Keep it boring.

WILL: Like, I’d love a boring day at work. Do you know how bad I love a boring day at work?

MIKE: [laughs]

WILL: Oh my God. Well, I could, like, put on a podcast and, like, I'm not, like, toweling my brow off, where I'm trying to, like, figure out what's happening. Or I'm just, like, I could just pretend I'm [inaudible 22:48], you know what I mean? It's, like, this is just easy, ta-ta-ta. Put some music on, you know what I mean? Just vibe out. Like, I'm not crunching, like, numbers, like, splitting the atoms in my brain. Oh, I get three of those days a month, maybe, and I mark them on my calendar [laughter].

DAVE: That's my grandpa's good day, right? Is go out into the oil field and pump jacks, and all he's got to do is just check on them and make sure they stink. Yep, they stink. We can go home.

MIKE: Well, I was thinking about this as you were bringing it up before. Hardware, so modern hardware is, in general, fast, and storage is cheap. I'm going to say never, but it's pretty close. Yeah, you're never going to use all that CPU, right? You're never going to use all that memory. There are cases when this is not [crosstalk 23:40]... There are violations of what I'm saying. But, in general, the hardware is cheap.

You know what's not cheap? Us. We are not cheap. And if you make us more expensive, you've done something wrong. Technically, we could hand-roll loops in Assembly and be optimizing all the time. But nobody does that unless there's some very special need because it is incredibly time-consuming and error-prone. And that costs time that relatively highly paid people need to take. And whereas make the hardware do it; make the compiler do it, means that we get to think in something much closer to English, or whatever our native tongue is, right? Something similar to natural language.

WILL: [laughs]

MIKE: What’s that?

WILL: I said, please no English.

MIKE: Yeah [laughs]. Something similar to whatever our native tongue is. Something that reads largely like natural language but is unambiguous. Forget the fact that LLMs exist nowadays, and they might do what you want, and they might not. Unambiguous language.

We're writing code for us. I've heard you say this, Dave, a lot. We write code for humans. Most of what we're doing is writing this documentation to ourselves and our peers, and the computer goes through a whole lot of work to make sense of it because we've set up a bunch of rules. But we design these languages around our understanding because, in the end, it makes financial sense. And, in general, we're doing this because we want to get paid. We're trying to support our families, and we're doing whatever it is that our aspiration is. We want to eat, therefore, we write code. And we don't want to take more cost than it should. So, we write things that make sense.

KYLE: One thing I'm thinking about is you said hardware. There's another environment where I feel like best practices get ignored even more and more, meaning more, like, reliability and modularity, and that's when you're working with microcontrollers. Anything actually in, like, firmware-based, you're very limited on the resources that you have. And the code, if you start looking at firmware code, because your memory modules are so small in some of these things, it's not readable. You need that master's degree or that doctorate to be able to even go through some of that code to figure it out, and be, you know, that these controllers are in Java these days or whatnot, you know.

WILL: No, they're not [laughs].

KYLE: No, they're not [laughter], but, you know.

WILL: It's really not because if you write it in nasty, old C, I can say [inaudible 26:39].

KYLE: It will run better. Yeah, but point being is, like, it's still, like, looking at a different language at some point, right, even if it's one that you're familiar with because it is so condensed. And you're not going to see the same best practices that you would if you were, you know, going for a full-fledged app for software-based.

WILL: I mean, I’d say, like, embedded device drivers, right, like, they have their own best practices, and it's, you know, I mean, like, it really is. I mean, like, they're not...I think everybody's trying to do the least amount of work they can before quitting time. I mean, and a lot of that stuff, a lot of it is sort of, like, you know, like, you're really not doing it in a way that’s, like, hard. It's hard work to think about, but it's also a lot narrower, right?

Because, like, you know, like, device driver, what are you doing? You're pulling bits off a bus, right? You're turning that into data, right? You're putting that data out to an address, right, you know, your memory mapped I/O, whether it's like, I'm going to save it out to a buffer so that, like, somebody can pick it up downstream. Or I'm going to, like, send these pins for this controller to move this, you know, motor or whatever the heck you're doing. I mean, like, it's actually…so, I mean, on some level, I don't want to, like, undersell, like, how hateful a process it is because it's not fun, and you don't want to do it. But it's also, like, once you break it down, you know, it's not so bad, you know. If you want some really, truly awful, hateful work, performance compilers.

MIKE: Gotcha [laughter].

WILL: You're getting all the smoke, all the smoke. You need to know, like, all the nasty work that's being done on the platform level, on the hardware level, at the language level, and, like, you've got to see anything that comes. Anything that comes in the door, you know what I mean? If your lexer, you know what I mean, will acknowledge it as a valid program, you've got to figure out some way to make it happen. Oh my God. I'm making web apps. No more of that for me [laughter]. [inaudible 28:58]. I'm done. No more.

JUSTIN: So, to kind of bring this back a little bit to, you know, you write some code. It does the thing that you need it to do in the moment. What's the next steps? Like, I've often created tickets that I put on my backlog, and I specified, here, I did a thing because of X, Y, and Z. We should fix it sometime. And then, of course, it sits there on the backlog until we, you know, we just ignore it for a long time. But do you guys do that? Do you guys, like, [inaudible 29:35] code, or do you create a ticket?

WILL: I love it, man. I'll put it in the sprint. I'll just be like, you know, I'll put it in the December sprint and just be like, "Hey, I did this," and, like, it seemed like a good idea at the time. And, I mean, honestly, it's like exponential backup, right? Where it's like, okay, listen, I have to hit my ship date, okay? I got to hit my ship date or else, you know, we're all fired, you know? So, okay, you know what I mean?

And then, like, maybe, like, two weeks out of the ship date, we're going to see where we're at. And then maybe a month later, and then, like, six months later, and then, like, a year later, and then, like, you know, like, every year. We'll be like, Hey, it's, like, a week before Christmas, you know? So, let's all look at our stockings. Let's all check our stockings for lumps of coal. Just sometimes when I'm like, listen, I know I'm not doing anything. It's, like, the day before Thanksgiving. We sure we're still good with this? Okay. You know, whatever. And, you know, it could be like [inaudible 30:43], where it's like, yeah, I did a bad thing but, like, the blast radius is small. The value is high. And I'm not, you know, I don't know [inaudible 30:55], you know. That's the next guy's problem [laughter].

MIKE: It's something that I was thinking about before, you know, before the call, I was writing down some notes. Some things are more important than others, you know, that sounds almost [inaudible 31:13] logical [laughter]. If there are two things of different importance, one is more important than the other. But it actually matters. There are things that matter a lot, and there are things that matter a little.

For example, if you have a piece of code that is getting hit over and over and over and over again…I had this happen once. There was some permission checking system in an app I was in that was, you know, of course, it was used dozens of times for every request you made because, you know, it's just checking all these permissions all over the page. And it was used all the time, and it was slow. It was terrible slow.

We optimized that, and, like, just that one thing. We optimized permissions, and the app went, like, twice as fast or several times faster. That code was important, right? It really mattered. We needed to make that run well, and so we did, like, some caching on it. Again, it makes it worse to read, but it mattered. It was enough. It mattered enough that it was worth getting the attention.

On the other hand, if you've got, like, a template, and you're on one page, and you like the idea of having it shared but, no, this other page needs to be a little bit different, then copy that thing. There's almost no cost to having another file and making it look a little bit different, yeah? There's a little bit of duplication. But you know how easy it is to copy a template? And you know how hard it is to try to share something between templates and make sure that that's right? And it's off a little bit, and then now it doesn't match anymore, and you're fighting that for years. That's a nightmare, right? Copy the file. Nobody cares. It'll work. And these are supposed to be [inaudible 32:51]. If it was going to be the same, you wouldn't have been asked to copy it in the first place. There are things that matter a lot, and there are things that don't.

JUSTIN: I mean, that goes back to the importance of grooming your backlog and everything. It’s like, you look at your backlog, and you look at all the tickets you've created in the last six months or month and a half or whatever. And you're sitting there, and it's like, what's the biggest bang for the buck? And you have a limited amount of time. The company has a limited amount of budget. That thing that you did to fix prod, that's gone. That's still working. And you have the choice between fixing that versus shipping new products that could be new revenue. That's an easy choice.

DAVE: I worked with a guy years ago who wanted to put some backlinks on our website for SEO. So, basically, he wanted us to give him the ability to just drop links into our website that would point to his other sites. Okay, that's fine. He's basically farming. What do the kids say? Farming aura but with Google. He's just trying to increase the amount of Google index rank that he can get. And I'm like, really? You're just jamming extra links? You're just stuffing links into all of these sites so that it radiates back? And he paused, and he goes, "It's a cheap trick, but it's a time-honored cheap trick." And I'm like, that's another great way to say best practice, in my opinion [laughs].

WILL: If it makes money, it makes sense, you know.

DAVE: Pragmatism. If it works, it's true. Absolutely. Pragmatism.

WILL: That's the truth, man. I can't fault it, really.

MIKE: In that backlog, we should probably not dive too much into this because we could end up spending a full session on this. We probably have before. But you've got to have some time on your schedule to be working on that backlog because if you leave a bunch of garbage around, eventually, you've got a big pile of garbage. And you do need to be cleaning up. That's, I think, a different discussion. You do put it on the backlog. You prioritize it. And you spend a significant amount of every sprint, or whatever your time interval is, working on it. Maybe that number is 20%, maybe 30%. Maybe you had a dedicated team that’s going through and just cleaning stuff. I've seen that work as well, and they're a meaningful part of it.

WILL: I’ll do it in my free time.

[laughter]

MIKE: Sure [laughter]. You've got to dedicate some time to it. I did take that rack off my bike, and I came up with a different solution. And I've got a trailer that's mounted to my seat now. It works great. The alternate solution has to be built. You're going to have to deal with that at some point. It doesn’t mean you made the wrong choice at the beginning, but you do have to get to it. So, I'm not advocating, yeah, make the mess. It'll take care of itself. But you should make the mess when you have to and prioritize what you fix, and then be working on the top priority item.

DAVE: You said something a few minutes ago, Mike, about some things are important and some things are not. And, for me, one of the toughest things to start, and this goes back to don't treat best practices like it's a Bible, the thing that's important might change. And two different things might be important to two different people at the same time.

In our architecture meeting today, we talked, and I think everybody here...Jordan might not be aware of this. We have two different ways to control whether or not a feature appears on the website. We have one way. We have a library that we wrote called system settings. And it will look at environment variables coming into the system, and you can set an environment. And we have these local files that we keep in the project that you can override or supply an environment variable if it's missing, and they're cascaded by environments. It's a nice fine-grained way to do it.

And It's super convenient as an engineer because I can say, here's this feature. I'm going to put the feature flag in the code, and I'm going to turn it off. And in my local code, I'm going to turn it on. I can test it. We can play with it. I can give it to QA. They can turn it on, play with it, test it, and da da da, and down the road we go. And when it's ready to go out, we just ship it to production. We don't have to involve DevOps. We don't have to touch anybody else. We don't have to do a dual deploy. We are good to go.

However, our deploy process is kind of lengthy. It's fairly long here, and the review process is even longer. This is not a fast way to turn a thing around. And sometimes, I think I've said this before, when the egg hits the fan, you need to be able to turn off the fan or the egg, one of the two. And for that, you need a kill switch.

We have this other system called Kipper, and Kipper is an open-source project. You can get it right now and play with it. It's fantastic. Kipper, you basically go to the Kipper library and say, "Hey, is this feature enabled?" And we have the advantage of saying, for this merchant, or for this customer, or for this class of users, or whatever, you can give it actors. And Kipper can say, "Well, it's enabled for that person, but not this," or "It's enabled for this logged in user, but not that." So, again, you can hide people back and forth. And you can go to Kipper, and you can turn it off, and it's off instantly. So, if something blows up, you can make it stop blowing up, or you can turn it off.

But this is the reverse problem. Now, if you want to ship something into prod, you have to go to our Kipper site, in whichever environment you're in: local, preflight, prod, whatever, dev. Whichever environment you're in, you have to go find that in Kipper. You have to type that variable in, which you're going to mess up once, right? We all did it once. And you're going to figure out why it's not enabled on the site. Am I the wrong user? There's all that mess.

There's a batch deploy. There's a tandem deploy for how to do this. And different users find these things indispensable. With Kipper, you can say, "I want to slowly cut traffic. I want just 10% of my traffic going here." Or "I want 50-50. I want to do A/B testing between the two." You can do that all with Kipper. System settings, now the flag is either there, or it's not. You could go in and say, "Here's 10 merchants that I want to be included in the system setting," and keep that in environment. But if you want to change those 10 merchants, you've got to do another deploy, right? Again, it's slow.

And we kind of went around the table a little bit in architecture because there are people on one side who didn't see the relevance of the other side, and vice versa. People are like, "Well, I need this. Who cares about that thing?" And the other people were like, "Well, I care about that." So, where we ended up with is, right now, we're going to continue using both systems. But we have an increasing desire.

And this won't surprise Mike, this has been coming up in architecture for three years, that maybe we'd like to have something that can do both. And it's just one place to do it in the code, and you can deploy it if you need to. You can turn it off instantly if you need to. You can filter it, A/B, whatever. But it's taken us three years of going around trying to determine what is the best practice, which one...and we haven't had a good understanding yet of like, "Oh, we need a solution where the best practice is to solve all of your best cases and all of your best cases." Those are constraints. It's not a best practice. There's two groups, and they both need the thing that they need, and because they're both true at the same time, we have two systems. If we replace them, we're going to have to replace them with a system that can do both things.

MIKE: But you're able to live with both of them for a while.

DAVE: Yeah, and I can't get my manager to give me six weeks to go write a new library to build a new thing that would do the thing. I'll make it a Rails engine. We can plug it in the app. It'll be so slick. Yeah, yeah. It'd be nice. It'd be nice. Making money for the company is more important.

MIKE: Let me throw one other time when I think it's a good idea to violate best practices. Play. There are times when you should break it on purpose when it's not in production.

DAVE: Yes. Yes.

MIKE: If you want to learn something, one of the best ways to learn it is do the wrong thing. There's this great thing, Juice Shop. It's [laughs] this system for learning web security, where it's a website that has everything wrong with it. It violates all the best practices for security. And you can go in, and you can do horrible things to it [chuckles] that should not be done because it allows you to do it. It's like a scavenger hunt. What are all the things that you can go in there and you can break? You wouldn't normally put up a web app like that, but you learn so much by having done it wrong.

I did something similar once years ago where we built our own web application. Over a series of weeks, we had a session a week where we would learn one of the OWASP top 10, and somebody would be assigned to violate the rule. We went through each of them and added some code somewhere in the app that violated one of the OWASP top 10 rules. And then the rest of the team, once a week, would have a chance to try to break it. And the team that I was with learned so much about security.

I don't think they ever went and put any of those vulnerabilities in their code ever afterward because they got it. I think that you learn a ton from violating best practices on purpose in a sandbox and should be actively encouraged to do so. There's something about the mental exercise of it. But we should deliberately set up situations when we're learning something, to break the rules, to figure out what those boundaries are because sometimes maybe you should. I mean, there's probably some cases where you should. Security? Maybe not. There's probably an exception here. Well, there's there, the Juice Shop. You violate security on purpose so people can learn.

In general, no, you never, ever, ever want to do that, and it makes it really hard. I remember trying to allow some SQL injection in Rails, and it was hard. I had to [chuckles] break so many things to let that through. And you learned a lot of what you had to do [chuckles].

JUSTIN: I, unfortunately, have seen that problem before in Rails [laughter]. They tried really hard, and they succeeded [laughter].

MIKE: It is possible, but you have to --

WILL: It's Turing complete. You can always break it.

MIKE: I saw a whole reporting system built once that was reliant, at its core, on SQL injection.

WILL: Oh.

DAVE: Fantastic.

WILL: I would also say, like, you know what I mean? Maybe, like, adding on to, like, play or a corollary for play, I think the value of a sloppy, like, prototype is just way, way, way undervalued. I find myself, like, because I like to write good code, and you know what I mean? And I don't like people dogging me out, you know, pull requests, you know? Because, like, I did something sloppy, and I'm just like, all right, I like, you know, I have a tendency towards golfing, you know?

But there's a lot to be said for just going out there and, like, just rip and run. And just make it fast, and ugly, and nasty, and just make it work by any means necessary. By any means necessary. Do things you know are wrong. Just like, yeah, this is all one function. Yeah, that's right.

MIKE: [laughs]

WILL: Psychometric complexity who? Get it. Like, we're doing it all. And then, like, you know what I mean? And then when it's done, like, I find, like, because again, like, I don't like thinking really hard. And it's a whole lot easier to look at, you know, an ugly, finished, working piece of code and look like, who wrote this? What idiot excreted this thing? You did this wrong, and this wrong, and this wrong, and this wrong, and this wrong. And this should go here, and this should be a class. This should be in a module. What are you doing? You know, like, that's easy work. Like, I find it effortless to be a hater [laughs]. And so, you know, just slap something together and fix it in post. I know that's, like, I know that feels counterintuitive to most people.

DAVE: Does it?

WILL: But, for me --

DAVE: Because what I just heard you say was get to green fast and then refactor.

WILL: Exactly.

MIKE: What I heard, like, I've been working with one of my kids through an English class, and he was assigned to write a first draft and make it sloppy [laughs]. He said, "Don't worry about grammar. Don't worry about making it pretty. Don't worry about what order things are in. Just get it out there."

DAVE: Yeah, I'm trying to teach you the process. Stop trying to produce a perfect document because you've got a way of generating that document implicitly without thinking about the process. And that means you are end-running the process to generate the document. I need you to stop generating the document and focus on the process. I may have had that conversation with another programmer recently, so I'm a little head up about that. Now, do it to hear…Okay, yeah, yeah. No, come back. Stop jumping ahead.

MIKE: You know, that first draft lets you start putting in that criticism. It's a whole lot better than having nothing to criticize. You may have your beautiful opening sentence. That doesn't get you very far. You can get a whole lot farther with a working product that you can then tear apart and put back together pretty.

DAVE: There's a million perfect sentences. And if you haven't figured out what the story is about, you've got a one in one million chance of getting it right. It could be a perfect sentence. It could just be the wrong one.

This goes back to that idea of the waterfall. You run the risk of working your way all the way up the ladder to discover that you built it against the wrong wall. And you don't know until you're at that top rung because it doesn’t work until...you can't even turn it on until you've got that last piece plugged in.

MIKE: Wasn't it a long-running joke in the Peanuts comic that Snoopy was writing a novel?

DAVE: Probably.

MIKE: And he had the opening sentence, "It was a dark and stormy night," and never got beyond that [laughter]. I think that strip was out for decades, and I don't think he ever got beyond the first sentence.

DAVE: I don't think so.

MIKE: And it was a perfect first sentence but didn't have the story. So…Go ahead.

JORDAN: I think this sounds similar to my personal experience of working on projects. Like, I know that I should be following...They tell us in school that you should be following best practices and doing things the right way. But when you have an idea, and you have motivation, and you're doing it slowly by following best practices, sometimes you just lose that motivation. But you have a perfect start, but you don't have anything as a result.

It goes back to your goals and pros and cons. If I have this motivation, and I make it quick, but it doesn't look the greatest, or it doesn't follow the best practices on readability and stuff, at least I'll have something, and it's there. And I think it's a lot easier to go back and fix it rather than continue trying to build something perfectly, so…

KYLE: You just described an MVP that they decided to ship to production [laughter].

DAVE: I would sometimes call that the triumph of YAGNI, where you'll come back to some code, YAGNI is Y-A-G-N-I, You Ain't Gonna Need It. And, basically, it's just pull yourself back a little bit and say, don't write a solution to tomorrow's problem. Trust tomorrow you to do that.

And so, sometimes I get into code, and I'm like, this whole thing is missing. I'm supposed to be adapting this, and the code to support it is gone. Who wrote this crap? Oh, the person who wrote it didn't need this piece. And thank God they didn't write it because it was factored differently than the way I would have needed it. This is not a stupid oversight or omission. It feels like a stupid oversight or an omission, but it's not. It's a triumph of the principle of YAGNI because you've left me clean field to build what I need to build. -

JUSTIN: Then you look at the blame history, and it was you. It was you.

DAVE: Oh, it's always me [laughter]. The call is coming from inside my own head, absolutely [laughter]. I have started...I've said this, but this is genuinely a sentiment I've experienced. I have started trying to be kind to future me when I write code. That's an actual thing I try to think of, be kind to future me. And you know what I've discovered? I've discovered that past me has started being a little bit less of a butthole when I'm working on my code. It's the weirdest thing. I have no idea what future me thinks about it, but past me is getting nicer and nicer. I'm actually enjoying it.

JORDAN: I feel like best practices, though, like the idea of best practice is to be nice to future you. So, like, I guess it depends on, like, what kind of practices you're following. But, in my mind, best practices is to make it easier for future you, even though, I guess, like, the whole point of this discussion was, what is the best thing to do in the present? So…

But it's the recurring theme that we come back to. If it's not simple, then you're probably doing it wrong, like, that should be your guiding principle. Make things easy on future you. And you only make an exception when you have to. There are times when that's right. You may have a performance reason you need to do something. Building a sophisticated caching system is a nightmare, but it solves a lot of problems, and there are times and places. But avoid it until you have to. I think that's a good place to leave today.

DAVE: This was awesome.

MIKE: Make it easy, unless you have to, and, you know, clean up if you can, if it's important.

DAVE: I would add, consider...make it easy on future you. But from time to time, think about how much it hurts right now and ask yourself if it's because of the thing that you did to make it easy. Sandi Metz gave me some advice about do this thing and then stop. And I got to that point, and I knew it needed to be refactored, and I spent two hours refactoring it.

Then she said, "Great. Can you understand your code?" And I went back and realized that after that stopping point, everything I did just added ceremony and unreadability to the code. And it was all what I thought was best practices, and I realized this was dumb. I should have been asking myself if I can understand this.

MIKE: Great. I think it's a perfect place to end. Until next time on the Acima Development Podcast.