Something I've noticed is that there's a distinction between short lived feature flags that are used as part of the CI/CD process to keep master stable and feature flags that determine which features a customer has access to, like product tiers. The CI/CD flags are temporary and need to be cleaned up quickly to reduce tech debt When people confuse the two it can lead to problems

With some features touching many files (Validator, UI, Service Logic, and Controllers); introducing a feature toggle can be non-trivial. I am considering deploying the new feature without a toggle to a staging server and directing small portions of traffic to the staging server until all users are then using the new feature. Similar to A/B testing and routing traffic to the newer deployment of the app.

Agree I've been in the situation where too many feature flags were disabled but they still exist in code, another kind of tech debt was created I guess

Hi. I don't remember if there was a video regarding using DDD in a legacy code, but I wonder how can we jump into legacy project with huge amount of sub-projects and 15 years dependency chain and impement a DDD (with or without CQRS or Event Sourcing). Is there a way how can we define our aggregates and bounding context and pass this smoothly? Or should we throw that idea and do as it always was done all this time before (by making yet another patch/workaround)?

They definitely are! (more than just Toggle that is!)

Just implemented a feature toggle to evaluate two different dates when calculating account expiration dates. Super handy as the feature will only be in our domestic deployment and not our international deployment.

Amazing channel, thank you. We need a video about authentication and advanced authroization in a microservices event driven architecture please.

I am currently implementing a custom feature flaging system with dynamic json editor front-end management that syncs the values from db and dynamically caches them for usage, so that the application admins has full access to rollout period and parameters. The most usefull thing that no stakeholder or product owner ever gonna think. Every tech lead in major enterprise workflow should push for a sprint like that.

Doesn't it become a centralised config store at that point? The lines are blurring.

Hey Derek, what do you think of services like LaunchDarkly? It's a great UI with many features for managing feature flags with reactive SDKs for consuming the feature flags, but maybe it isn't the right move to add the outside service dependency for any business critical logic.

testing is a nightmare!

First of all, this is a really good channel. I've subscribed to it and enjoyed many vids here. Secondly, I think it's worth pointing out that there are also other ways to improve on his approach by utilizing better code design. As he says, in their basic and "naive" form, feature flags can be seen as (1) "if/else" conditions in the application with (2) an effective way to specify which conditional path to go by means of some kind of configuration elsewhere. Now, "if/else" conditions have implications on CNN and OCP: CNN: Every additional condition in your code adds to the CNN (Cyclomatic Complexity Number), i.e. your code will be MEASURABLY more complex. OCP: If you have to change the existing code to insert the feature flag conditional then you're violating the OCP (Open Closed Principle which is the "O" in S.O.L.I.D.). Therefore I try other techniques first and insert conditionals only if I have no other realistic option: 1) One of his examples is a feature flag to turn on/off a cache or select which cache to use. Caches are a textbook example of the DECORATOR pattern. This allows to wrap the data provider transparently into a surrounding implementation which can then function as a cache. No implementation code needs to be changed for this to happen. The only thing left to do is the configuration part. There you MIGHT need a conditional for the factory that wraps one into the other. However, you may also leverage your Dependency Injection (DI) container or use annotations and/or AOP tooling for this. 2) Another way to create a feature flag would be to use good old polymorphism. Your feature is then a new implementation of the "thing" it is being swapped for. If, instead, your feature is not REPLACING anything existing but is ADDITIONAL functionality then put the functionalities (old and new) into a list and iterate over the list. The configuration will decide whether to put the new feature in or not, which makes it, in effect, a feature flag toggle. The rest is how you configure which implementation is to be used where or added to the list of features. This is typically the job of a DI container or similar mechanisms. (I think Derek is kind of thinking this direction in his second example about the "tenant". However, his example still interprets a boolean to change the app's behavior. My approach on the other hand specifies the concrete implementation class to be used or not, i.e. the is no need to interpret anything thus keeping the CNN from growing.) Sometimes, this requires existing code to be refactored first so that the pieces can be separated by polymorphic implementations. If the effort and/or risk for this effort is too high I do admit that we may end up with the traditional if/else conditionals instead.

I don't think long-term toggles should be called Feature-Flags. The problem is that if you have a feature-flag in the system, then during testing you'll need to check all combination to ensure that your system works as expected. If a flag in production never changes it's value after a rollout, then said flag needs to be removed. Then you end up having these nested dependencies that flag X only works if feature Y is on etc. #IMO it's a lot cleaner if one doesn't mix short lived feature flags with long term values for configuration. So if different deployments support different caches (to stick with the example) then said cache should be configured via a different source then feature flags. (Also if a feature gets released and needs to be supported in the long run, then said flag should be migrated over to this other location) Also long term configs tent to resemble a hierarchy while short lived flags are usually flat. I've seen deployments with 680+ feature flags still in the system. Now good luck testing that...