PurePerformance - What's next for Feature Flagging and OpenFeature with Ben Rometsch

Episode Date: February 3, 2025

Feature Flagging - some may call them "glorified if-statements" - has been a development practice for decades. But have we reached a stage where organizations are doing "Feature Flag-Driven Development?". After all it took years to establish a test-driven development culture despite having great tools and frameworks available!To learn more we invited Ben Rometsch, Co-Founder of Flagsmith, to chat about the history, state and future of Feature Flagging. He is giving us an update on where the market is heading, how the CNCF project OpenFeature and its community is driving best practices, what the role of AI might be and what he thinks might be next!Couple of links we discussed during the episode:Ben on LinkedIn: https://www.linkedin.com/in/benrometsch/YouTube Video on Observability & Feature Flagging: https://www.youtube.com/watch?v=VZakh1_oEL8OpenFeature: https://openfeature.dev/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance Are you already had a beer? No, no. Well, no, that was not the lie. But as he said, as always. And unfortunately, we have rare moments where we have to record a podcast without each other. Well, it's usually, I think, I don't even know if there's ever been one when I did it without you. So when I'm doing it, it's as always. If I'm saying it, it's true. In this case, it's true.

You're right. Right. How would in this case it's true. You're right. Right? How would the computer interpret it? Anyhow, we're not here to talk about language. Because this could be interpreted one or the other way. Yeah, we're here to be patriotic. We're talking about flags.

Flags, yeah. Maybe some maybe, how can I make now this connection from flags to feature flags? Let's just say it out loud. Feature flagging. Feature flagging has been a topic at least from my side for the last couple of years because the promise of feature flags when I first heard about the term, before that when I developed software, I had many if statements in my code

that were basically saying, if this, then do this. But if a particular Boolean variable was on, then execute a particular piece of code. This obviously matured much more than what we had back then. Some still call feature flagging glorified if statements, but to get a better description

of what feature flagging is, what the state of feature flagging is, where the industry is going, we invited Ben from Flexwith today. And Ben, thank you so much for being on the show. How are you doing? Yeah, thanks for having me. I'm really good, thanks. Yeah, really good. Hey, so Ben, when I say glorified if statement, a feature flag is nothing else than a glorified if statement.

Do you cringe? Do you feel like... No, I mean, we lean into that, I think. The kind of the beauty of the pattern is its simplicity and its effectiveness and how you can get such a large benefit just from, you know, the original way back in the mists of time concept of doing it. I think the thing that the big thing that changed was the idea of having those things become remotely switchable, which was, you know, what changed from your and everyone else's back in the very early days. There wasn't a really reliable way of doing that remotely. But yeah, we definitely lean into it and we see the bulk of the value of the idea and the concept and people who use Flagsmith or

one of the other vendors or even Rothering, if you can organize yourself around them and your workflows around them, then they're super powerful and they're just Booleans, yeah. So that's a good way maybe to explain kind of also the maturity and how the things has evolved because back in the days, as I explained, I remember during startup with an environment variable that initialized the variable that I could access in my code, and then I basically said, hey, if A, if true, then do this, if false, do something else.

Now, modern feature flag management, really one of the features is that you can change these things on the fly remotely, but I believe it goes much further. You can do a lot of conditional evaluations right so um where you can define rules uh i guess you obviously folks if you are interested in learning more about future flagging there's also a lot of material out there that we will also link to so as we go through this discussion today and as we talk about additional

content that people should look into folks you, you will find the links in the description of the podcast. Now, Ben, to hear it from your perspective, if I look at your website, it says ship faster and control releases with feature flag management. You've been doing this for quite a while and I would just be interested now because we've been hearing this for a while what's the adoption what's the real adoption of feature flagging right now out there because I think some people may still are still not comfortable with it because changing something dynamically on the fly which means it changes the execution of code on the fly just give us some confirmation. Is this things that people really doing at scale? Yeah, I mean, 100% they are. We, you know, we're constantly talking to companies of all

different shapes and size. We're a commercial and open source platform. So, you know, we're getting everything from like hobbyists, people doing stuff in their basements on home labs and stuff, which, you know, it's really well suited to all the way up to, you know, massive, huge multinational corporations and everyone in between. I do think that the direction of travel in the last kind of 20 years, I mean, I've been writing software professionally for over 25 years now. And, you know, that direction of travel of back then, it was like there would be this enormous amount of energy behind a single release. And, you know, that release might stay in production for many, many months, right? Whatever you were talking about. I mean, I know it sounds kind of crazy now, but that's how software used to,

well, the software that I was involved in very much used to be designed, built, and that was the kind of velocity of those releases. And the direction of travel ever since then has always been to um you know collapse that time between releases you've got the you know the the kind of the pedestal engineering teams um especially you know 10-15 years ago who were pioneering multiple releases a day, not having... I used to work with testing teams that would be in an entire room,

and there would be human beings that would just go and literally go through the same processes day after day, just testing that stuff. This was before all of the automated browser testing stuff. So that's a long way of saying feature flags are a small part of that concept where I guess back then it sounded counterintuitive to say we're going to deploy our software 12 times a day and that's going to make it more, you know, it's going to improve quality, reduce defects, downtime, all this sort of stuff. seniority level of large organizations to understand that counterintuition is actually proven again and again in all different shapes and sizes of teams to be,

if you can release more often, there's a general correlation between quality and how often you can release software. Does this mean, because I think both Brian and I have a huge background in quality engineering, we've both been on the testing side, on the performance testing side, before performance testing, I also did a lot of functional testing. Does this mean that with feature flags,

we no longer need those people that are doing manual testing that are creating automated tests is this is feature flagging kind of eliminating the need for upfront testing no i mean it's definitely not a silver bullet um i think that's that's a little bit of a that that's a common i think that's a bit of a common misconception. Sometimes people think that at one stroke they can be in this new world of not having to do a bunch of stuff that is maybe not the exciting part of engineering. But that's not the case. one sort of component part of a whole ecosystem of tooling and infrastructure and workflows and processes that can get you to that to that point of um you know fix forward um not not you know people not knowing that a build's gone into production almost.

Like, again, that sounds super counterintuitive. And the first time I heard that, you know, however many years ago it was, I was like, this is just nuts. Like, but then, you know, you had, there was a very, in the UK, a challenger bank called Monzo who famously said, you know, we've got one environment of production. We do multiple releases a day. They just, they got a banking license. And so it's definitely part of a lot of tooling around

a whole suite of stuff, things like zero downtime deployments, things like really high quality reactive observability platforms like Dynatrace, you you know uh reliable dependable cicd processes being able to deploy your software without any downtime and being able to do that consistently and repeatedly so there's a whole there's a whole sort of you know and i i talk about this a lot i kind of 25 years ago you know you were going and racking machines into um data centers by you know that was what the engineering team had to do to get sites live um uh doing a deployment without or with you know a few seconds of downtime was tricky um and often involved switching shells as quickly as you could to turn Apache back on or whatever and where the industry is now where the discipline is now

and you know it's kind of almost unthinkable to show someone know, if I could go back to my 20-year-old self and show them what the tooling was and how much time it's freed up, how much more efficient and effective it's made teams. And feature flagging is definitely, like, I mean, I believe it's an important part of that, but it's definitely not a silver bullet. I mean, Flagsmith itself has a very um

comprehensive uh end-to-end front-end set of tests a huge amount of of server-side tests um and you know it's it's all about the the you know the the increase in quality that it gives you and the increase in work efficiency, developer productivity. So there's a bunch of stuff going on. But a lot of this stuff is not about tooling or software or infrastructure either. A lot of it is about people and workflows. And I would say that the pull request page of GitHub is probably as important an invention as anything else. And anyone could write a pull request page, right? Like it's just a bunch of comments and stuff.

So yeah, it's definitely, I find it quite interesting because it's not just technology. It's people and processes and opinions and politics and a lot of that stuff. And that's why it's quite interesting working with different types of organizations. You know, some of them very kind of like classically slow moving, you know, non-engineering industry organizations and things like that. And they're very much a lot of the time, you know, progressive and trying to get to that point. But it's just because of their size. That's a 10 year program kind of thing. Well, thanks for all this background. And I think, as you mentioned, Feature Flakes is just

a technical detail on how we need to change the way we think about releasing software. It's about decoupling the deployment from the release. I think this was a big thing for me still. Some of the questions are, you know, how do you still test? Coming back to the testing aspect, how do you test that you're deploying something new and the feature flags are all turned off? That still you actually made the right, you put the right code behind the feature flag and you don't miss anything.

Also, if you have cross dependencies between feature flags, I think these are still some challenges that might be tooling around it to figure out if the cross dependencies are not a challenge. But overall, it's just a technical detail on how to implement the feature flag.

It means more about how you're changing a development process and your release process. And I really like your example with the analogy with the pull request page, right? Because the pull request page is a very simple page, but it changes completely the way you think about the software delivery process. And I think that's a spot on analogy. Yeah, I mean, almost all tooling has been going in that direction, right? Like observability platforms, source code control and management, deployment, they've all been moving in that direction. And, you know, they're all important.

And, you know, they can all play well together um but just to go back to your um point about you know whether how you do testing with like cross-dependent flags again like these things are just tools and um you know anyone um uh can can can you know you can misuse tools so you know you know, thinking about making flags that are kind of functional, right, in a way that you've, you know, if you had a purely functional language that only takes inputs and outputs

and can't mutate the state of the rest of the program, quite often, you know, it's, well, we generally recommend people think about feature flags in the same way. And so that's one of the reasons why we're really great proponents of using them, particularly on the front end as well, because it's much easier to make a feature flag kind of purely functional in that it's not going to have any knock-on effects on other parts of the application if you're just, you know, removing a menu item or showing an additional option or something like that. So like all these things, you know, I mean, yeah,

by itself, Git doesn't do anything, right? And you can tie yourself into knots using a version control system or using a CI CD platform or using feature flags. And so a lot of what we work on is, I mean, it's not, I wouldn't describe it as consultancy, but definitely like speaking to customers, finding out, you know, how they're using the product, how big their teams are, whether the teams have cross dependencies, they have microservice architectural monoliths and all this sort of stuff, whether they have a monorepository.

Because all those things feed into and can give people an idea of what the best way of using flags are. It's really common as well for us to help teams just get started, you know, get that first feature out that they've gated through a flag and turned on in production through a flag. That's obviously, you know, especially from a person, a people point of view, that can be a lot of work, can be challenging. It can mean, you know, it can even mean at the most extreme level organizations changing their policy on what they define as a release, right?

Like a good example is financial services in the EU. There needs to be, there's an amount of regulation about whether you're, when you change your application or your application behavior, who's allowed to change that, what sign off you need to do that. And obviously, introducing feature flags can then blur that quite a lot. So, you know, you could even be getting to the point where just using the pattern requires you to, you know, get board level sign off on, right, we're going to change our sort of engineering policy around this. So, yeah, once you get the first deployment under your belt, then it's a case of like, right, you know, how can the rest of the team use this? How can the server-side engineering team use this? And how can the SREs use this?

And, you know, how can the mobile app teams use this? And, again, like most tools, they can be overused. You know, we've seen deployments with, you know, hundreds and hundreds or thousands of flags, and sometimes it's just a little bit crazy. Actually, if you open your Chrome browser, and you go to Chrome slash slash flags, you can see how many feature flags are available in the Chrome browser,

and there's many. Obviously, that's an incredibly complicated piece of software, you can see how many feature flags are available in the Chrome browser. And there's many, um, obviously that's an incredibly complicated piece of software, but, um, yeah, it's, it's different like all these tools,

um, how you use them depends on, on who you are and what you want to get out of them. And there's no, there's no real rules for everybody that, that work, that work for everybody really. Yeah.

Hey, as you mentioned, this use case with the regulations, so obviously you have the need as an organization, let's say in the EU, to change certain rules at midnight because then a new law cuts into effect and only certain people are allowed to make this change. Thinking broader,

if I have a handful of feature flags, how do I make sure that I also know exactly at which point in time which feature flag was active and also evaluated? Because in the end, feature flag is like configuration change. And so I always want to make sure if something breaks or if I get an audit, right? If I get an audit by the European Union, I need to make sure to explain that at one hour before midnight,

this code was really not executed, but at midnight, this code got executed. The term S-bomb also comes into mind, like the software bill of materials. Is this where the whole feature flag configuration also becomes part of your s-bomb or how does this work do you have any ideas on that yeah i mean that's a big question um i mean for sure um you know you are you all of engineering's trade-offs and and um you are trading off some aspects of you, reproducibility and understandability in the edge cases of bugs or, you know, which line of code was lit, which, you know, which code path was lit at, you know, 9.57 last night because, you know, something happened. There was some, I don't know, security vulnerability or something like that. And this is kind of, I've been thinking about this a lot recently, actually.

I've kind of come up with this concept that we talk about flags just being Booleans, but enterprise software, you know, it needs this very large, wide, heavy stuff around it, right? Like it needs audit logs and it needs different forms of authentication and it needs integration with different types of, you know, enterprise systems and it needs fine-grained access controls and all of this sort of stuff. And it doesn't matter what you're doing.

It doesn't matter whether you're just doing feature flags or if you're building a platform of the scope of, you know, Dynatrace or GitLab or something like that. They all need all of that stuff around them to to be able to you know for for us where when we're selling into large enterprises those you know there's as you i'm sure you've seen the 500 question excel spreadsheets of you know what's your ssl certificate policy and what authentication mechanisms do you have and all this sort of stuff um and so a lot of what we've been working on um in the last couple of years has um been answering questions like that

so yeah you know you've got and and and um uh this this is where we can sort of talk about about open feature um open telemetry um and being able to yeah like you know so this this idea that you're you're right you're completely right that your flag state for that user or that session at that moment in time is part of your configuration building materials whatever it's what you need to be able to reconstruct you know if you need to go back and look at what happened why some error was thrown or exception was thrown why why it was thrown and it does become part of that black box of all of that stuff that you'd expect to get in a trace and so things like integrating into um you know open telemetry So those flags states that that particular mobile application had in memory at

that time become part of a trace. And so you can say, okay, yeah, you know, we turned on this feature midnight last night because, you know, we left the European union or something equally annoying. And we had to change, you know we left the european union or something equally um annoying and um we had to change you know the the regulation changed and the law changed we had to do something um and so you know the you know that's something you can use a flag management platform like flagsmith or one of the other vendors to do is to say right you know at this point in time at you know 11 59 i want this flag to be false and at 12 midnight i want it to be true and so

that's obviously um needs to be stored somewhere you need to be able to recover that in an audit log or a trace or something like that so you can so you can understand it um and so yeah so a lot of the work that we've been doing on flagsmith, the developer experience probably hasn't moved much in the last couple of years because it doesn't need to, because that stuff kind of is there and works. And a lot of the stuff we've been doing is around things like integrations with OpenTelemetry or Grafana or something like that, where those more unusual, difficult questions of what was the state of the application for this user at this point in time,

we can give a good answer to that. Yeah. Yeah. For me, it was a nice segue because initially when we talked years ago, the reason why we were enriching distributed traces with feature flag information was mainly for troubleshooting purposes and for reporting purposes. That means how many people were now seeing the new feature and did this have any positive or negative impact or did it fail?

And if so, was it because of this feature flag? Yes or no. So we are enriching distributed traces and maybe logs with this information. The additional use case that analysis the whole compliance use case, if compliance is the right word, I think it is the right word that you can prove now with a distributed trace that is enriched with feature flag information that a certain user was served a result with this feature flag turned on to enforce a certain new, let's say, regulation. And I think it's not only with regulatory bodies. I believe also in the e-commerce space, if you think about a new launch of an iPhone, I'm pretty sure all the vendors have a certain contract

that they are only allowed to put the iPhone out there at a particular point in time. Nobody can sell earlier or tickets or something like this. And so the trace becomes even more important because you can also use this to prove that you have done your job right,

that you are within your contractual obligations. And I never thought about this until you just mentioned this. Yeah, I mean, it's funny you mentioned the iPhone one because there's always one vendor in one country that presses the button and does it like 24 hours too early and then everyone's got the specs. And then they're obviously never going to be able to buy anything from Apple ever again.

Yeah, exactly. Yeah, I mean, especially with distributed systems, ironically, that's gone from a very easy problem to solve to a quite hard one. It used to be like, well, just turn that version of the site off and bring that version of the site up and restart Apache. That's how you used to do that 20 years ago. But with more distributed systems now, it becomes an increasingly non-trivial thing to solve, for sure. Without flags, that is, right?

You brought up Open Feature in conversation earlier. Open Feature is an open source, a CNCF project that was launched three years ago now at QCon Valencia between a couple of organizations, including Dynagrace. You were also one of the early adopters in supporting OpenFeature. Just for a clarification perspective, because I sometimes also get serious that people get the difference wrong between OpenTelemetry and an observability platform.

OpenTelemetry is a framework that standardizes the way you're collecting data, but it's not an observability platform. You still need to send this data to someplace to then analyze it. And the same is true with open feature. Open feature is a standard that allows developers to put in feature flags in their code without the, let's say, link to a vendor implementation. But still, open feature on its own doesn't do anything without a backend. And there might be open source backend implementations. And the same is true for open source observability platforms

that can consume open telemetry data, but you still need that backend. Is there anything, first of all, clarification? Did I miss anything to explain? No, that was a great summary. That was a great summary, yeah. I mean, I think trying to trying to yeah i mean the the original goal i think really back in the early day was to try and um design an interface standard for

the sdks so that um it was it was easy to well not just to switch provider but also to to be able to swap out um like flag provider implementation. So just to give people a good example of that, if you're wanting to run isolated unit tests that don't have external dependent, so you don't want them to have external network dependencies, being able to swap out a real-time flag provider like FlagSmith with, say, a flat file of flag values, right, that you want to run your unit and integration tests against.

That's something that is a very reasonable thing to expect and to ask for from a feature flagging platform. And one of the things that we kind of underestimated when we started the project was how much energy that those SDKs would consume and the expectations of quality and capability of those SDKs. And as a small team, it was very difficult for us to, you know, people would come to us and say, I want to be able to swap out my Rust SDK with some static flags. And it's like, well, again, that's reasonable. But, you know, we've only got a finite amount of engineering resource. And so Open Feature, as well as being able to provide a common interface standard that people can write their code to and be able to swap out providers. It also adds a load of flexibility that, you know, the static file unit testing is a

good example of that. But then one of the other great things about it is because it's not the flag implementation itself, it still needs the Flagsmith SDK or the LaunchDarkly SDK or whatever. There's parts of that runtime that it has access to that means that it can do things like send that trace into OpenTelemetry without us as Flagsmith, as a vendor, having to do that. So for us being able to write those adapters for the different languages to plug our SDKs into OpenFeature, you know, some days I wake up in the morning and look at the OpenFeature repository, and it's like, oh, this language, Open Feature SDK has suddenly acquired this new capability because someone in the community implemented it.

And if you're using Flagsmith as a provider, you get that for free, we get that for free. And it's like a perfect example of how open source makes the world go round. So there's a bunch of stuff there, especially for a relatively small team like ours, is just super great. And we just believe that the core philosophy of the project is right. This is a perfect example of where standards are.

I mean, standards, as I would describe it, as just ones that generally become, you know, the kind of lingua franca of dealing with, with flags. And so, yeah, it's, it's been great to watch it, to watch it grow and, um, to see the capabilities of it grow. And also, you know, you were asking about where, um, where feature flagging is in terms of its sort of its journey and its maturity and the thought the sorts of things that we're talking about within the open feature community are probably a good proxy of where that is because the questions are becoming um much more um you know specific yeah, around like observability, around, you know, driving and reporting A-B testing and things like that. And so, yeah, it's kind of in the same way that

Flagsmith went through that maturity of, you know, just being able to just do flags and then to be able to, you know, take it to become more, you know, enterprise rich or, you know, be able to take it to become more enterprise rich or be able to drive and integrate with, say, A-B testing platforms or A-B testing data stores, Open Features is going through that same process. But it's kind of a little bit more difficult in that regard because I think there's definitely, we talk about this a lot within the Open Feature team, trying to decide where the boundary ends, because that's a super critical design decision for the project. And when to say, that's out of our remit, there's another project that would be more relevant for that or you know that's just that's just not relevant so to get into that is definitely the the first um first couple of years of the project it was it was just a ton of work to do and it was all very easy decisions and easy choices almost non-choices really and that you know this just needs to exist

and you know you maybe maybe argue a little bit about specific schema things or what have you, but now it's getting to the interesting questions of should we support A-B testing and to what degree should we support it? Also, the technical solution has become more complicated because there's different opinions about how you should do that sort of thing and all sorts of stuff. But it's been super valuable experience for me watching that project grow for sure. I have a final thought or final question or area that I want to go towards the end of the podcast, which is, and maybe I misheard you earlier, but I think what you said is

that feature flagging technically, it's a solved problem technically. Technically we have simple feature flags, we have complex evaluations, you can do all sorts of things. We have the auditing. Yes, as a feature flag management vendor, you have certain complex evaluations you can do all sorts of things we have the auditing yes as a feature flag management vendor you have certain integrations you need to build but feature flagging itself it's a solved problem does this mean that innovation is kind of from a tooling perspective technology perspective getting towards an end but is this the chance because you said earlier you're now

doing a lot of consulting you don't want to call yourselves consultants but you're really advocating and helping large organizations to really change the way they do software development and delivery is this is this the next evolutionary step so we have have the technicalities down and now it's about really helping organizations to adopt this technology. It's like going back 20, 30 years we had unit testing frameworks but the frameworks on it

on its own, they don't do anything. You need to teach developers how to do test driven development. I mean, I think that's a great analogy actually because you're right like um uh you know i don't know how old j unit is um it's got to be it's got to be 20 years old right and at least yeah uh you um it's still you know not uncommon to i mean but actually really really common you know flagsmith came out of an agency that i was running and from time to time we do not uncommon to, I mean, actually really, really common.

Flagsmith came out of an agency that I was running and from time to time we do help companies through software audits, security audits, technical audits, things like that. And I mean, even in large banks, I won't name any names for certain, but it's really, really, really kind of uncommon to find uh software projects with with good unit test coverage right like um and you know if you're writing some little

side projects on a weekend then fine but if if you're writing some um you know i don't know um kyc workflows for for a bank then you probably want to have unit tests. And so, yeah, I think it's a great analogy. You know, it's kind of unit tests, you know, unit tests are a little bit like brushing your teeth, right? Like, you know, when you're a kid, you know, you should do it. You don't want to, you don't really get any benefit out of it. But it's just something that, you know, when you're a kid, you know you should do it. You don't want to. You don't really get any benefit out of it. But it's just something that you know that is a good idea.

Feature flags are kind of a little bit more interesting because they're more obvious in their payback for engineering teams right like i can put this thing but if i'm waiting for someone waiting for another team or waiting for a microservice to finish this bit of work and it's going to take them a week i can put my stuff behind a flag push it live get on with my life and go do the next thing right um you know unit tests don't really give you that that that like immediate kind of like sort of win of like right i can just do that or you know i think i you know if i need to turn this feature off in australia or canada then i can do that really quite easily with feature flags um but i do think that yeah you're definitely right like as a a, it's kind of like an advocacy thing now, almost more than, you know, how do they work?

How'd you do them? You know, most engineers now, even if they've not used them themselves, when you work, when you, you know, when we do a walkthrough of the platform, there's nothing like, oh, I didn't, you know, there's no like, oh, my God, I didn't expect it to do that, right? It's like, yeah, that's all fairly obvious as an SDK and an API key and all that sort of stuff. And so the interesting thing about that is that when it comes to advocacy, everyone in that industry is pulling in the same direction right like um we're advocating it and

um you know our competitors are advocating it and open features advocating it and all this stuff um and so that kind of makes life a little bit less um kind of competitive and uh in a way because like everyone's kind of putting in the same direction and a lot of this boils down to one of this is one of the questions that obviously we'll never get an answer to but we're always debating um within within flagsmith is what percentage of active software projects in the world are currently using some form of you know either feature flags or feature flag-like stuff, right? If you were to squint, you'd go, yeah, that's a feature flag.

And I don't know, you know, we don't know what that number is, but I still think it's low double digits, right? Like quite very low double digits. And so that, you know, that's kind of like how we perceive it at the time, really. And I do think conceptually and in terms of, um, feature set, um, most of the platforms out there, um, are, you know, they might do things slightly differently and they might have slightly different concepts around, um, certain different things, but, you know like we're always

trying to make the platform um lower latency and more reliable and all this sort of stuff and make things like unit testing easier and quality quality of life stuff for engineers rather than like you know there's this suddenly there's this like version you know this we're currently on version two dot whatever and i can't imagine ever there being a three right like unless we change the versioning system which maybe we maybe we'll do for that reason yeah yeah no but yeah but it enough also proves the point that i made earlier right i think you are technically you are technically you've reached almost technical completeness. There's always certain things you need to do,

but the big hurdle now is to advocate, and it seems the whole industry is advocating for this. It's the same that we are advocating for observability-driven development. You need to, from the start, understand and have a strategy on how to observe your software and you need to define what makes your software healthy or unhealthy because if you don't do this you will patching it later on it's not easy and and and it's just like flying blind and the same is true with feature flags legs feature of leg driven development is something that we probably see

going forward yeah um we are almost at the end and brian i haven't heard much of you today you've just been sitting there and listening and sucking and soaking everything in no there are several questions i was going to ask that then got answered there but i i guess the final question i have, right? So this is the scenario I can imagine. I imagine it's pretty easy to get set up and running on initial feature flags, right? But as my mind works is the more I start thinking about it, the deeper I start thinking about it. It's like, well, what should we do as a feature flag?

What should we not do as a feature flag? When you start thinking about dependency and then maybe even feature flag debt and all these other things, you know, my mind starts, you know, going out of control. So what is there out there for people who are looking to go do feature flags? Is it like consulting services that companies like Flagsmith offered, or offer or you hire a consultant? Or is it just communities? Like, how do people learn to grow and mature with feature flags so that they don't dig themselves in a hole they can't get out of later? We don't offer consulting services

as a standalone thing. We have customer success folk who help our customers. And, you know, and then we have like a Discord community where, you know, every now and again, yeah, like people drop in and go and ask a question related to that. There is some tooling around it that's fairly common amongst providers. And so, for example, being able to label flags as permanent. So there are some use cases of flags where they are going to live for the lifetime of the project.

And then generally, providers have tooling around stale flags. So in Flagsmith, anyway, I can talk to Flagsmith. If a flag's not marked as permanent, but it hasn't had a state change for a particular amount of time, I can't remember exactly how long it is at the moment. You know, you can get a list of right, like these flags haven't, no one's touched them for like six months. And they're not permanent or you haven't marked them as permanent. And so that's probably, you know, that's a smell. And there's definitely engineering smell there that you're like, you know, go and figure out. And then, you know, again, like you can associate flags with team members in Flagsmith.

So you can go, oh, you know, this flag, Andy wrote, created this flag like two years ago. No one's touched it for a year. It's in this report. I'm going to ask him, like, you know, what happened? He'll go, oh, you know, yeah, that went live like 18 months ago. I just completely forgot about it. It's fine. Like, we'll put it in the next pull request.

We'll just, you know, turn that on and we can remove the flag. So there is some amount of tooling around that. But, you know, I'm going to repeat myself again. These things are kind of like societal as much as tooling, getting into that habit of part of your development cycle being, yeah, what's in that stale flags list? The lovely thing about pull requests and being able to deploy software whenever you

want is that you can just do these little rhythms all the time um and front you know engineer and and flags help you increase that that rhythm one of the things that they add to and you sort of get used to doing once you start using them is you know um write the feature, write the unit tests, get it into production, and then a month later or two weeks later or whatever, remove the flag and just remove the conditional from your code kind of thing. And it's when you get that additional step as part of your, as part of your workflow that it just becomes part of that kind of housekeeping that you do. And, you know, people might be thinking, Oh God,

you know, that's the, you know, the last thing I want is another, you know, kind of thing. And, and, and you know i think actually this is this i'm not massively into the kind of ai hype train i know it's kind of a bit more fashionable now to be in that in that camp but that would be a great you know i'm sure we're pretty close to having claude or gemini or whatever you know gpt being able to look at, you know, in the same way that they're really good at writing pull request summaries now, that's a great use case for AI.

Just go like, right, yeah, you know, I've got, I can understand Flagsmith's state. I can see your code. I can see all the changes that are going through there. And his flag hasn't changed for a year and a half. Here's the pull request to remove that flag. And then here's the, I don't know, API or Terraform script to turn that off in Flagsmith. Like, that's definitely, I'm on that AI train, definitely.

Like, that sounds like a great thing. And probably, yeah, I mean, we're probably there in terms of the abilities of the lms now yeah cool cool yeah great to end it on a on a hype topic god no i wasn't gonna i said i'm not gonna mention ai this hour but and i think it will also make a good a good soundbite I took a couple of notes today throughout the presentation on which soundbites to use but maybe this one in the end is the one that we will pick Ben, thank you so much

for being on the podcast, it's always amazing how fast time flies and I know we will see each other most likely at KubeCon in London or at least we'll figure out a way to meet there. Will you, will Flagsmith be there as well, like with the booth? We'll definitely have some folk there. The KubeCon booths are not the cheapest in the world,

so we're not exhibiting, but we will be there in body and spirit, just not in cold, hot cash, I guess. Maybe people will find you around the Open Feature booth because they will have the project pavilion there. Yeah, so there is definitely

that's been another thing just to add. It's been great to see the evolution of evolution of open feature in the context of KubeCon, and there are significant things going on, open feature related in KubeCon. I guess that, you know, if you're interested in terms of hacking on the projects,

working on the SDKs, getting advice on the best way to use the tool. So yeah, check out the KubeCon agenda because there's significantly more open feature-related stuff there than there has been in the past yet. Yeah, and if you get your people at KubeCon to just wear top to bottom

Flagsmith logos and everything, they could just be a mobile booth. You know, you can have iPads or whatever, or tablets on their chest so they can demonstrate, right? Yeah. You don't need to be stationary. The system.

Alright, anyway, thank you so much for being on the show really really appreciate it it's just fascinating yeah no thanks for having me and we look forward to hearing what comes of this in the future

glad to hear you said you're all in on AI for everything yeah and thanks everyone for listening talk to you soon bye bye bye bye bye Yeah. And thanks everyone for listening. Talk to you soon. Bye-bye. Bye-bye.

Bye.