21–30 of 54 posts
> Hardcoded feature flags ... start with a simple JSON file Any configuration read out of a JSON file is not hardcoded. Hardcoded means you need to recompile to change it. (And yes, hardcoded, as in flags set with #define or equivalent, are totally fine depending on what you're doing.)
> Hardcoded feature flags ... start with a simple JSON file Any configuration read out of a JSON file is not hardcoded. Hardcoded means you need to recompile to change it. (And yes, hardcoded, as in flags set with #define or equivalent, are totally fine depending on what you're doing.)
The blogspam marketing behind them is so strong
I am on my second feature flag startup, but I also somewhat agree with this. Every project should have flags, but many projects need just the basics and a service is overkill. Rolling your own JSON still feels like something we ought avoid though. Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be…
Your second startup dedicated to feature flags ? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
I am on my second feature flag startup, but I also somewhat agree with this. Every project should have flags, but many projects need just the basics and a service is overkill. Rolling your own JSON still feels like something we ought avoid though. Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be…
Your second startup dedicated to feature flags ? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
There can be whole UIs and tooling and infrastructure to manage around them and that’s what the sass offer
I am on my second feature flag startup, but I also somewhat agree with this. Every project should have flags, but many projects need just the basics and a service is overkill. Rolling your own JSON still feels like something we ought avoid though. Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be…
Your second startup dedicated to feature flags ? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
In my experience these (configuration based feature flags and feature flag services) are actually two complimentary capabilities that solve two completely different problems but that happen to share the same name: feature flags. The config approach is critical for using feature flags as a software development lifecycle tool. It is how you manage having a codebase which contains the unfinished code for new feature x,…
Examples:
Experiment flags for A/B testing
Permission checks at a user level
Product flags for feature gating by plan
Rollout flags to launch a new feature gradually
Configuration for an account/system/feature
The number of times I had to push against the “just put it behind hasFeatureFlag(user, flag)” is more than I can count at this point! I think it comes from a misunderstanding of the DRY principle, to be honest.
In my experience these (configuration based feature flags and feature flag services) are actually two complimentary capabilities that solve two completely different problems but that happen to share the same name: feature flags. The config approach is critical for using feature flags as a software development lifecycle tool. It is how you manage having a codebase which contains the unfinished code for new feature x,…
Strongly agree that Config & FeatureFlags are two different things. But as I've tried building tools in the space: man is it difficult to really nail down what the difference is. For Quonfig I landed on: - Data model wise they are identical. Flags and configs can both be targeted. They can both use segments. They can both do partial rollouts. They can both have the same range of values (bool/number/duration/json/json…
There are no solutions, only tradeoffs.
I'll give some examples:
Firm 1 had a single server running tron [0] for ALL scheduling of processes.
Pros: very easy to see what should run when and made audits a breeze
Cons: the central server died and it was a giant outage response to make sure that when the server came up it didn't start killing processes that should be running
Firm 2 used a management gui to create custom cron entries on each machine
Pros: each node had a local copy of the schedule and could keep going even if the central system died
Cons: each node had a local copy of the schedule which could "drift" from other nodes, a node could be forgotten etc
So, more generally, I agree that it's good to label things as "ok" so that we don't get into flame wars etc. That being said, the more important point is to say that if you are going to pick a strategy, do the work to support, build tooling and plan for outages related to that strategy.