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

It's OK to hardcode feature flags

code.mendhak.com

Post reply on HN
Print view View original

21–30 of 111 posts

Re: It's OK to hardcode feature flags

#21

Post by tomnipotent »

elliot07 wrote: post #13
simonw wrote: post #5

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

I agree with a lot of this, except for the part about de-risking deployments. That should not be a reason why to adopt a feature flag platform - that is a symptom of a bad deployment pipeline that should be fixed which is a whole other story.

> That should not be a reason why to adopt a feature flag platform

It's one of the two big reasons. First is the ability to rollout features gradually and separate deployments from feature release, and second is the ability to turn new features off when something goes wrong. Even part of the motivation of A/B testing is de-risking.

Re: It's OK to hardcode feature flags

#23

Post by traverseda »

simonw wrote: post #5

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

Why aren't you just using environment variables for feature flags?

Have people still not bought into the whole 12 factor config things?

Re: It's OK to hardcode feature flags

#24

Post by mlinhares »

elliot07 wrote: post #13
simonw wrote: post #5

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

I agree with a lot of this, except for the part about de-risking deployments. That should not be a reason why to adopt a feature flag platform - that is a symptom of a bad deployment pipeline that should be fixed which is a whole other story.

Strong disagree here, my whole org does not roll out changes without feature flags at all and whenever someone doesn't follow this policy they cause large scale incidents. Feature flags are actually a sign the deployment pipeline is very sane and mature, because people understand any new code comes with unexpected risks and we should prevent these risks from taking down systems.

Re: It's OK to hardcode feature flags

#25

Post by mattmanser »

simonw wrote: post #5

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

I've been doing this a long time and seen a few different apps use config in database. There's different levels of config you're talking about here, but general app config should generally not go in a db.

No-one ever changes the bloody things and it's just an extra thing to go wrong. If it only loads on startup, it achieves nothing over a bog standard config file. If it loads every request you've just incurred a 5% overhead on every call.

And it ALWAYS ends up filled with crap that doesn't work anymore. Because unlike config files, no-one clear it up.

Worse still is when people haven't made it injectable and then it means unit tests rely on a real database, or it blocks getting a proper CI/CD pipeline working.

I end up having to pick the damn thing out of the app.

Use a config file like everyone else that's probably built into the framework you're using.

To be honest, most of the time I've seen it has been when people who clearly did not know their language/framework who wrote the app.

I'm not saying it's you, but that's been my honest experience of config in the db, it's generally been a serious code smell that the whole app will be bad.

Re: It's OK to hardcode feature flags

#26

Post by jitl »

Kwpolska wrote: post #10
simonw wrote: post #5

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

Often these 3rd party offerings are feature flags PLUS experimentation with user segmenting. Depending on the style of software you build, this can be extremely valuable; it’s very popular in the SaaS market for a reason.

Early on at Notion we used simple percent rollout in Redis, then we built our own flag & experimentation system, but as our needs got more complex we ended up switching to a 3rd party rather than dedicating a team to keep building out the internal system.

We will probably hit a scale in a few years where it makes sense to bring this back in house but there’s certainly a sweet spot for the 3rd party version between the 50-500 engineer mark for SaaS companies.

Re: It's OK to hardcode feature flags

#27

Post by CBLT »

elliot07 wrote: post #13
simonw wrote: post #5

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

I agree with a lot of this, except for the part about de-risking deployments. That should not be a reason why to adopt a feature flag platform - that is a symptom of a bad deployment pipeline that should be fixed which is a whole other story.

I disagree that using feature flags to de-risk deployments is a symptom of bad deployment pipelines.

There's several aspects of deployments that are in contention with each other: safety, deployment latency, and engineering overhead are how I'd break it down. Every deployment process is a tradeoff between these factors.

What I (maybe naively) think you're advocating is writing more end-to-end tests, which moves the needle towards safety at the expense of the other factors. In particular, having end to end tests that are materially better than well-written k8s health checks (which you already have, right?) is pretty hard. They might be flakey, they might depend on a lot of specifics of the application that's subject to change, and they might just not be prioritized. In my experience, the highest value end-to-end tests are based on learned experiences of what someone already saw go wrong once. Writing comprehensive testing before the feature is even out results in many low quality tests, which is an enormous drain on productivity to write them, to maintain them, and to deal with the flakey tests. It is better, I think, to have non-comprehensive end-to-end tests that provides as much value for the lowest overhead on human resources. And the safety tradeoff we make there can be mitigated by having the feature behind a flag.

My whole thesis, really, is that by using feature flags you can make better tradeoffs between these than you otherwise could.

Re: It's OK to hardcode feature flags

#28

Post by jitl »

traverseda wrote: post #23
simonw wrote: post #5

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

Why aren't you just using environment variables for feature flags? Have people still not bought into the whole 12 factor config things?

When your app starts to get bigger and more complex, the idea of needing to restart a process to pick up any new kind of data starts to seem silly.

Have seen the pattern many times:

Hard-code values in code -> configure via env -> configure slow things via env and fast things via redis -> configure almost everything via a config management system

I do not want to reboot every instance in a fleet of 2000 nodes just to enable a new feature for a new batch of beta testers. How do I express that in an env var anyways? What if I have 100s of flags I need to control?

In other cases I need some set of nodes to behave one way, and some set of nodes to behave another way - say the nodes in us-west-2 vs the nodes in eu-central-1. Do I really want to teach my deploy system the exhaustive differences of configuration between environments? No I want my orchestration and deploy layer to be as similar as possible between regions, and push almost everything besides region & environment identification into the app layer - those two can be env vars because they basically never change for the life of the cluster.

Re: It's OK to hardcode feature flags

#30

Post by traverseda »

jitl wrote: post #28
traverseda wrote: post #23

Earlier quoted context omitted.

Why aren't you just using environment variables for feature flags? Have people still not bought into the whole 12 factor config things?

When your app starts to get bigger and more complex, the idea of needing to restart a process to pick up any new kind of data starts to seem silly. Have seen the pattern many times: Hard-code values in code -> configure via env -> configure slow things via env and fast things via redis -> configure almost everything via a config management system I do not want to reboot every instance in a fleet of 2000 nodes just to…

How do you do software upgrades if you don't have a good system for handling process restarts without downtime?
Post reply on HN