Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's OK to hardcode feature flags (2025)

code.mendhak.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: It's OK to hardcode feature flags (2025)

#41

Post by esafak »

hasyimibhar wrote: post #38
esafak wrote: post #35

Earlier quoted context omitted.

Why would you not use the same service to handle them? Less is more.

Having worked at a large company that misuses feature flag service for everything, here are some examples why you shouldn’t: - one team uses feature flag for product gating. Feature flag service goes down. Users temporarily got locked out of the features they paid for. - one team uses feature flag for dynamic pricing by leveraging targeting rules (how hard is it to write a bunch of if else in code?). It’s evaluated a…

> - one team uses feature flag for product gating. Feature flag service goes down. Users temporarily got locked out of the features they paid for.

That could happen if they used a separate service. In this case you need to build defaults; open or closed, as the case demands.

> - one team uses feature flag for dynamic pricing by leveraging targeting rules (how hard is it to write a bunch of if else in code?). It’s evaluated against all users, even if they are not active (for analysis reasons). Feature flag service charges by MAU. We have millions of users. Our feature flag service bill is now 6 digits per year.

This is a valid reason if you don't own the service, as it seems you don't. If you did, you should have asked your internal customers what their requirements were.

> - one team uses feature flag as literal json store instead of a proper db (god knows why). Someone updated the value but the “schema” is wrong. Shit breaks.

Separating the services would not help here. They are simply using the wrong tool.

Re: It's OK to hardcode feature flags (2025)

#42

Post by Pannoniae »

torginus wrote: post #36

I just wanted to say I haven't been doing C# dev until as of late, and I forgot how flipping amazing the tooling is. One of the things the C# compiler (which is used for IDE tooling) can do out of the box is it can compile multiple versions of the file (syntax, and symbol resolution included), meaning you can still make sure the statically disabled codepaths are still valid, and all the symbols are consistently avail…

looks like we've circled back to the good old

  #ifdef FEATURE_AI_V2
;)

Re: It's OK to hardcode feature flags (2025)

#43

Post by jameshart »

esafak wrote: post #41
hasyimibhar wrote: post #38

Earlier quoted context omitted.

Having worked at a large company that misuses feature flag service for everything, here are some examples why you shouldn’t: - one team uses feature flag for product gating. Feature flag service goes down. Users temporarily got locked out of the features they paid for. - one team uses feature flag for dynamic pricing by leveraging targeting rules (how hard is it to write a bunch of if else in code?). It’s evaluated a…

> - one team uses feature flag for product gating. Feature flag service goes down. Users temporarily got locked out of the features they paid for. That could happen if they used a separate service. In this case you need to build defaults; open or closed, as the case demands. > - one team uses feature flag for dynamic pricing by leveraging targeting rules (how hard is it to write a bunch of if else in code?). It’s eva…

Golden rule of large scale software dev: any system you expose that allows other teams to write text to it will eventually be used by another team as an ad hoc JSON database

Re: It's OK to hardcode feature flags (2025)

#44

Post by jollyllama »

kalcode wrote: post #21
gwbas1c wrote: post #20

> 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.)

That's a bit too rigid of a definition. Just means it requires a code update to change it, that's hardcoded.

It depends if the JSON file is in source control, or if it's an environment file.

Re: It's OK to hardcode feature flags (2025)

#45

Post by jdwyah »

quietbritishjim wrote: post #19
jdwyah wrote: post #11

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.

heh. yes.

First one got acquired. But also I wish I'd built it differently from the start (git based, other lessons learned), so started over.

It's true that it's a pretty simple thing, but you do want them to be of the utmost level of reliability. Its ideal if you can use feature flags & dynamic config (which I think of as the same problem) right at boot time. But then of course you have an external dependency to booting you app. So the reliability angle becomes imperative. So I do think the SaaS can play a good (or bad) role in overall reliability vs something you implement in house.

The other major advantage is telemetry. Once you have things toggling on and off, immediately engineers will get confused about whether something is on or off and why. Basic internal apps usually don't have any good telemetry / debugging. So a good SaaS should give you all kinds of ways to ensure that you can see what context is being passed around to the SDK to do their eval. Sanity checking etc.

My og experience was at HubSpot where we used the hell out of dynamic config. Once you get used to things like instantly targeting debug log levels for a single class to a single org its hard to go back.

Re: It's OK to hardcode feature flags (2025)

#46

Post by avlcodemonkey »

If you're working with C#, Microsoft added first class support for feature management in .Net with https://github.com/microsoft/featuremanagement-dotnet. It provides the logic for simple on/off, user targeting, percentage roll outs, and schedules. Using feature management along with flags hardcoded in `appSettings.json` makes perfect sense for a simpler application.

When your architecture grows and you start needing to synchronize configuration across multiple applications, or have non-technical users change flags, then you've probably outgrown hardcoding and need to consider building (or buying) a service. You probably don't want product owners trying to set an env var like `FeatureManagement__NewFeature__EnabledFor__0__Name`. Azure App Configuration is the go to if you're willing to use Azure - it provides a nice UI for editing flags instead of dealing with JSON. Or, I've been building https://featureflags.app/ as an alternative provider if you prefer to steer clear of Azure. Its kinda the middle ground between hard coding and a full on platform like LaunchDarkly.

Re: It's OK to hardcode feature flags (2025)

#48

Post by jdwyah »

scott_w wrote: post #28
jameshart wrote: post #12

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,…

I 100% agree with everything you said and more. I spent a significant amount of time at my job arguing constantly with the entire engineering department that “Feature Flags” are not all the same thing and had to push back on efforts to mix them all up. 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 C…

oo yeah.

entitlements is a huge one. Sooooo many orgs are in an absolute rats nest of confusion because half their entitlements are in something like an auth system, half are in something like billing and the third half is hacked into feature flags.

One particular pain point is that finance or something "do users with access to feature X retain better and it's super hard to figure out.

My overall feel is that developers are trying to solve a problem and that it turns out the configuration is as fundamentally as important as the software itself. I define "dynamic configuration" as "a key value store which takes context and has rules based system to give you a value". This primitive turns out to be extraordinarily useful and powerful. Rather than try to split it into N different systems, each custom / don't have telemetry / aren't available to all services SDKs. What if you have ONE BIG CONFIG system that really does a bang up job.

(Note: copying the big boys is not always the right move, but https://research.facebook.com/publications/holistic-configur... does give some credence that this is a decent approach)

By focussing on one terrific system, you can put all your eggs into the basket of making that reliable / comprehensible / flexible / strict.

The one on your list that I think DOESN'T belong would be permission checks at user level. The N of that is not a good fit for config (though when you look at the facebook paper, it's pretty wild how they've scaled it (but it doesn't do permissions afaik)).

Re: It's OK to hardcode feature flags (2025)

#49

Post by ozim »

I disagree because I have business people to have discussion with different customers on different timelines.

I can't hard code any of the flags until I have big customers notified and onboarded with the change.

So one would say why aren't your customers onboarded with the change before you implement it. Well no because they have 20-30 other applications they are using on daily basis.

While yeah we can push some customers to new features, we still need to have some realistic adoption in place before we can switch ... mostly because we are not Attlasian or Microsoft — we have actual people taking angry calls and angry e-mails from the customers.

Re: It's OK to hardcode feature flags (2025)

#50

Post by lpribis »

chasd00 wrote: post #37
Gigachad wrote: post #13

Earlier quoted context omitted.

You need to be actively deleting them after the feature has gone live

i could see it getting complex with a lot of flags, inevitable you'll run into a situation where more than one flag is combined. something like enabledFeature = (flag1 || flag2 || flag3) && flag4 then, down the road, you remove flag4. Hopefully the above would result in a compile error but you may be in a language or situation where a missing flag4 is interpreted as boolean false. That could cause all kinds of havoc…

Surely the commenter means deleting them in the code, not just the management software. Otherwise, what's the point?

You need to find every occurrence of flag4 and remove references to it. So that boolean expression would need to have `&& flag4` removed.

Post reply on HN