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

31–40 of 54 posts

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

#31

Post by gejose »

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.

The author literally spells out why this isn't always the case:

> 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 nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.

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

#32

Post by not_a_bot_4sho »

maxidog wrote: post #8

I’m currently reverse engineering a large enterprise app and the feature flag bloat is truly astounding. Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers.

> Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers.

In my experience, engineers aren't using them to account for managerial dithering, they're doing it for safe deployments and experiments and rollouts and such. A product with millions of users can easily have a tens or even hundreds of active switches at any moment (I'm assuming a large engineering team behind said product), and that's not necessarily a bad thing.

However, as someone else noted here, you absolutely MUST delete and clean up your flags/gates/whatever when you've completed that effort. That part can be tricky because not everyone has the discipline to pay off tech debt.

Usually, a flag/gate should not live in code for more than a few months. If it does, it should have robust justification.

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

#33

Post by jjice »

The biggest problem I've found with feature flags of this nature (mostly for internal testing and the like) is that they can easily live too long and bloat code. This is also very dependent on what the feature flag on/off code paths do.

1. For reducing outliving, I always create a ticket to remove the flag at the same time it gets added in. This way there's documented work that will get scheduled. YMMV depending on how your team does planning.

2. For flag branch implementations, it's often fine to do an if/else, but I've seen this blow up into a real headache. When I can, I like having two implementations of an interface that get swapped between. Code calls the interface as normal the the underlying implementation is the same. Works for React components and larger implementations/changes that already have an interface. Don't want to force an interface where it feels wrong.

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

#34

Post by retired »

jjice wrote: post #33

The biggest problem I've found with feature flags of this nature (mostly for internal testing and the like) is that they can easily live too long and bloat code. This is also very dependent on what the feature flag on/off code paths do. 1. For reducing outliving, I always create a ticket to remove the flag at the same time it gets added in. This way there's documented work that will get scheduled. YMMV depending on h…

It might depend on your programming language but what worked for my team was to have a file with all the feature-flags as enums/constants. That way you have a clear view of how many feature flags you currently have in your code and by CTRL+clicking you automatically see all the code associated with that flag.

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

#35

Post by esafak »

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…

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

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

#36

Post by torginus »

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 available in every feature flag combo.

When something does go wrong, the compiler degrades gracefully, and still can make sense of most of the code.

MS gets a lot of flak (sometimes deservedly so), but they can sometimes also show what a large organization of skilled individuals working under consistent direction is capable of.

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

#37

Post by chasd00 »

Gigachad wrote: post #13
maxidog wrote: post #8

I’m currently reverse engineering a large enterprise app and the feature flag bloat is truly astounding. Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers.

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 in logical combinations like that are scattered all over the codebase. Even worse would be REST APIs retrieving flag values because who knows what's happening in that service code? Plus, you'd never know there was an issue until users start reporting missing or extra features showing up unless you have e2e tests for every possible combination of feature flags...

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

#38

Post by hasyimibhar »

esafak wrote: post #35
scott_w wrote: post #28

Earlier quoted context omitted.

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…

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

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

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

#40

Post by liampulles »

Like many "cloud native ideas" there is a core 20% to the idea of feature flags that is useful to 80% of teams, and then a remaining 80% of periphery concerns that are relevant to 20% of teams (and I'm erring generously on those figures).

Specifically, the idea of putting toggles on risky functionality is a good idea that is useful broadly. Being able to dynamically toggle feature flags without a restart, or apply some features to some segment of users is unlikely to be useful and entails a lot of complexity and potential footguns.

My approach to feature flags is even simpler than what is suggested here: feature flags are just a section in your config. Done. Even if you are confident that you need more advanced capabilities, you should not "advance" to that level until you have demonstrable proof that your team can manage simple config values for it.

Post reply on HN