It's OK to hardcode feature flags
code.mendhak.com
It's OK to hardcode feature flags
1–10 of 111 posts
Re: It's OK to hardcode feature flags
#21. It's ok if deployment is quick and no customers are affected, but if you're running something like a whitelabel fast food app platform with a deployment cycle that takes a minute, that's enough time to get irate customers
2. The author obviously doesn't understand the importance of flags for new features which may break the customer experience when they dumb it down to the color of a button. I stopped wasting my time reading when I got there.
Re: It's OK to hardcode feature flags
#3If you have enough traffic then you’ll want to roll out new features gradually, and revert them quickly if despite your testing it causes trouble in production.
If you don’t have much traffic, and can live with having to redeploy to flip the switch, then fine, stick it in a config file.
But I clicked through expecting a defence of hard coding feature flags in the source code (`if true` or `if customerEmail.endsWith(“@importantcustomer.com”)`). I very don’t approve of this.
Re: It's OK to hardcode feature flags
#41. It's ok if deployment is quick and no customers are affected, but if you're running something like a whitelabel fast food app platform with a deployment cycle that takes a minute, that's enough time to get irate customers 2. The author obviously doesn't understand the importance of flags for new features which may break the customer experience when they dumb it down to the color of a button. I stopped wasting my t…
Funnily enough, deployments are faster than changing the environment variables. Probably something to do with the high sensitivity of some variables.
Re: It's OK to hardcode feature flags
#5The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot.
I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change and using an (often expensive) feature flags as a service platform: roll your own simple system.
A relational database lookup against primary keys in a table with a dozen records is effectively free. Heck, load the entire collection at the start of each request - through a short lived cache if your profiling says that would help.
Once you start getting more complicated (flags enabled for specific users etc) you should consider build-vs-buy more seriously, but for the most basic version you really can have no-deploy-changes at minimal cost with minimal effort.
There are probably good open source libraries you can use here too, though I haven't gone looking for any in the last five years.
Re: It's OK to hardcode feature flags
#6I've had an issue with gitlab feature flags when gitlab became unavailable. I couldn't fire a new deploy and the system wouldn't work until gitlab came back to life.
That was a stupid dependency.
Re: It's OK to hardcode feature flags
#7It's even okay to hardcode them into code (not a config/json file). Depending on the build pipeline this is similar to preprocessor flags, and the code will be removed during build.
It might be enough to test new features with a limited audience (beta build, test deployments for stakeholders/qa).
If done correctly this solution can be easily extended to use a feature flag management tool, or a config file.
PS: removing new features during build/tree-shaking/etc adds some additional security. In some cases even disabled features could pose a security risk. Disabled features are often not perfectly tested yet.
Re: It's OK to hardcode feature flags
#8The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…
Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.
Re: It's OK to hardcode feature flags
#9The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…
> build-vs-buy
Roll your own. Seriously.
Feature flags are such an easy thing that there should be a robust and completely open source offering not tied to B2B SaaS. Until then, do it in house.
My team built a five nines feature flag system that handled 200k QPS from thousands of services, active-active, local client caching, a robust predicate DSL for matching various conditions, percent rollout, control plane, ACLs, history, everything. It was super robust and took half an engineer to maintain.
We ultimately got roped into the "build vs buy" / "anti-weirdware" crosshairs from above. Being tasked with migrating to LaunchDarkly caused more outages, more headache, and more engineering hours spent. We were submitting fixes to LaunchDarkly's code, fixing the various language client integrations, and writing our own Ruby batching and multiprocessing. And they charged us way more for the pleasure.
Huge failure of management.
I've been out of this space for some years now, but someone should "Envoy" this whole problem and be done with it. One service, optional sidecars, all the language integrations. Durable failure and recovery behavior. Solid UX. This shouldn't be something you pay for. It should be a core competency and part of your main tooling.
Re: It's OK to hardcode feature flags
#10The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…
> using an (often expensive) feature flags as a service platform
I have no idea why anyone would actually do that in real life. Feature flags are something so trivial that you can implement them from scratch in a few hours, tops — and that includes some management UI.