Joel and Aaron dive into a friendly debate about the true nature of feature flags in software development. Drawing from their varied experiences across different programming languages and environments, they explore whether feature flags should always be temporary or can serve permanent purposes. The discussion evolves from a simple disagreement into deeper insights about different architectural approaches.
Sign up for free to get those amazing Laravel tips delivered each day
- (00:00) - Newsletter tips undergo careful peer review process
- (02:15) - Debating if feature flags should be temporary
- (05:25) - Different uses of feature flags across languages
- (07:20) - Feature flags in modern Laravel applications
- (08:35) - Silly Bit
Sign up for free to get those amazing Laravel tips delivered each day
Creators & Guests
What is No Compromises?
Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.
Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.
And this is Aaron.
What the listener may or may not know is that every tip I write for the newsletter goes through the careful scrutiny of Aaron's watchful eye. You know, just like with code where we have a pull request review process and there's some back and forth, same thing for every tip article.
And a lot of that is... I mean, there's code in there so that makes sense there but also we can develop our thought process together. So in general we agree on most things, yeah.
Yeah. And I find it very helpful because sometimes you will, say, point out a word that I've used that maybe could be considered not desirable. Not to give specifics, I'll leave it to your imagination. Or just a different-
Or all the f-bombs that Joel uses, I have to constantly get them out of there.
I am just the worst that way. But, you know, you just bring a different perspective and I find that useful. But as we were prepping for today's podcast, I learned that you actually disagreed with one of my recent tips. And I am shocked that it got approved and I want to talk about that.
Yeah. It's not so much that I disagree with the whole tip or that the tip was wrong. And that's just subjective too, right? I'm not saying that I know everything either. I mean, that's why we're all here, we're all trying to learn more, right?
Sure.
I think you can read and understand someone's point of view and not agree with it, and still see that it's a valid point of view. Or that most of it seems valid and there's no reason to pick on that. Especially these times in our world, everyone wants to drag down and fight. I'm just like, "No," I agree with 80% of what Joel's saying, and most of that's right. And I don't see any technical problems so it's good to go. I'll give a little context. The one I'm referring to was you most recently, couple of days ago, maybe... who knows what time, wrote a tip about feature flags. And one of the things you kind of went into how they can be used and all these different things. The title was 'Feature flags are meant to be temporary.'
Yes.
And that's the part that I disagreed with.
Okay. So, I'll set it up for, I guess there's probably somebody out there that hasn't read the tip. But the general idea I was putting forward is that, in my view, feature flags are temporary. They serve a purpose as you're rolling out something new, at some point it becomes stable and then you want to clean up the feature flag. So the thrust of the tip was how to build your feature flags in a way that you're not spreading them throughout your entire code base and they can be cleaned up easier if you want to remove them in the future. So, what part of that... Well, the temporary bit I guess doesn't harmonize with your experience.
Right. I agreed with that in all cases of it. In the cases that the feature flag is temporary, everything you said I agree with. But my experience comes from a little bit of different languages as well, like yours. And one of the languages I worked with was RPG IV on AS/400 or system i, and those developers had a different system than we do. It's this idea of cascading libraries and data in specific locations and stuff, almost like a PHP include path, things kind of fall back and you can find stuff. So one of the things that we were responsible for was writing code for five different companies and most of those companies had all the same requirements. Some of the companies had slightly different requirements. So we're talking about-
As they always do.
Yeah. And we're talking about like a old system. Like, it started with RPG III and then moved to IV. So RPG III even was like where you have code on the screen in the column matters. Like, specific column places meant specific things. We're talking about an older system that is made for processing data and it's really fast, and it was more efficient in that way to set up those systems with feature flags for the specific, almost, environment. So we might refer to them as environmental configuration in Laravel or something like that, they were using it as their feature flag system. So that's what I mean, is I don't think they're all temporary is that code was meant to always exist. And it's like for four to five companies we call this yellow, for the fifth we're going to call it maize. And that was a feature flag based off of what set of criteria context was using this code. You might almost think about it like they were doing it in a very simplistic form of a strategy pattern that was maybe swapped in and out. Except that it didn't have those polymorphic calls and all that different stuff that we can do in more object-oriented languages.
I'm just over here thinking, "I thought you were younger than me." But you're talking about RPG and system i, what is going... Like, what percentage of people listening to this right now even know what that is, Aaron?
Sorry.
But okay, so I'm absorbing what you said. And maybe my definition for feature flag is too narrow then. Like, I was literally thinking about it in terms of rolling out a new feature. But you're saying in some contexts, like this RPG world, feature flags were used also for just control flow, like configuration?
Right.
Okay. Just to push back a little bit, what about in the Laravel context? Because that's who the audience is for the newsletter. It is called Mastering Laravel, after all. Have you seen that same sort of use of feature flags or are you're just extrapolating that somebody out there probably still is doing it that way?
Yeah. I mean, I haven't seen this firsthand yet in Laravel but the Laravel Pennant and other feature flag systems are relatively new. Relatively... I mean, within the last couple of years.
Sure.
And I've seen them a lot as those temporary sort of feature flags. The other thing I've seen is the ability to do an A/B testing sort of thing. But not for getting a result, really just to split, not to split traffic, but to split functionality in... I guess it was for a result, but it wasn't like this is temporary, this was just we want to run... I guess it was temporary, but it was long-term temporary. We want to run 20% of our users through a different flow for the next year to see if that changes their experience. So I guess that's temporary but it just feels like longer-term than the kind of concept you were referring to.
Yeah. And it is a different concept than rolling out a new feature. It's like, no, there's just going to be two paths or three paths or whatever. And maybe even... I don't know, I'm just trying to go with your line of thinking here. Even some customizations that are sort of market or geography-based, you could use feature flags to implement some of that logic too. So maybe the feature flag, the technical thing of how you determine if a feature is on or off, is sort of separate than the use case. Whereas I was kind of focused on one use case of rolling out a new feature in a controlled way, there's all these other use cases for that technical mechanism.
Yeah. And kind of to wrap this up, one of the points you had was, let's not put all these feature flag checks everywhere. And that's still valid, whether or not it's a temporary one or a full-time one. Let's try to, you know, put those in a very centralized place. And also feature flag identifiers being enums, things like that, so you can keep track of them. Regardless of the way that you want to use that, those are all great tips, and anyone who hasn't read that tip should definitely go to it and read it. I got a really personal question for you, Joel.
I love those.
As a child, did you eat paste?
Oh boy. I definitely have a memory of somebody in my class being a notorious glue eater. Paste, glue, same thing?
I think the paste was the thicker stuff that like, maybe you had a container and maybe there was a stick in it or something. And glue, like Elmer's glue, would come out. I'm talking about the paste, like it had its own unique smell.
I'm sure I've tasted it as a kid. As a kid. But I wouldn't say I regularly partook.
I was just thinking about that the other day. All those things, like I don't think I ever really thought about eating paste until someone said, "Don't eat paste." As a kid, what, in kindergarten, I didn't really want to put any glue in my mouth. I understood what it meant when someone said, "Don't eat paste," and I was like, "Well, we got to start smelling this at least."
That's right. It's like when someone says, "Don't think about X," like that's the immediate thing you think about.
No, I think about Twitter. Little secret here at the very end. I was trying to say the name of our website and I forgot it.
Well, I know what it is, Aaron. It's masteringlaravel.io and if you'd like to sign up to get those tips delivered to your inbox, you can do that right from the homepage.