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

41–50 of 111 posts

Re: It's OK to hardcode feature flags

#41

Post by marcosdumay »

mattmanser wrote: post #25
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% o…

For some kind of software, another call to the DB is the best way to add bog-standard functionality without adding complexity and failure modes.

Granted, not for all software. And there's something to be said about a config file that you can just replace at deployment. But that's something that varies a lot from one environment to another.

Re: It's OK to hardcode feature flags

#42

Post by vijayer »

The call out on premature optimization is valid. However this article misses the mark on a couple fronts.

One, as others have called out, is the ability to control rollout (and rollback) without needing a deployment. Think mobile apps and the rollout friction. If something goes wrong, you need a way to turn off the offending functionality quickly without having to go through another deployment or a mobile app review.

Second, is to be able to understand the impact of the rollout. Feature flags can easily measure how the rollout of one feature can affect the rest of the system - whether it is usage, crash rates, engagement, or further down the funnel, revenue. It’s a cheat code for quickly turning every rollout into an experiment. And you don’t need a large sample size for catching some of these.

By having this power, you will find yourself doing more of it, which I believe is good.

Re: It's OK to hardcode feature flags

#43

Post by j45 »

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…

Great summary.

Just starting with them and learning to improve your application of them is the best way to learn, too.

There is one book on feature flags that had been written earlier, some of the independently published books by experienced tech folks out there are a goldmine.

Feature Flags by Ben Nadel is one such book for me. There is an online version that is free as well. Happy to learn about others.

https://featureflagsbook.com/

Re: It's OK to hardcode feature flags

#44

Post by fizx »

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.

If I was a bootstrapped startup, I'd do a json file and then when I've outgrown, I'd hand write something that long-polls a CDN for updates, with a tiny rails or react app behind the CDN.

But these approaches are insane for companies above a certain size, where individuals are being hired and fired regularly, security matters, and feature flags are in the critical path of revenue.

Last time I looked at LaunchDarkly Enterprise licensing, it started at $50k/year, and included SAML.

Now that sounds like a lot, but if you're well past the startup stage, you need a tiny team to manage your homegrown platform. Maybe you have other things for them to do as well, but you probably need 3 people devoting at least 25% of their time to this, in order to maintain. So that's at least $175k/year in the USA, and if your company is growing, then probably the opportunity cost is higher.

Re: It's OK to hardcode feature flags

#45

Post by fizx »

hirsin wrote: post #11
Kwpolska wrote: post #10

Earlier quoted context omitted.

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

You'll still be building management UI over their system (it doesn't understand or validate actor types, tenants, etc, so you have to do that.). But at high throughput, you might want something with dedicated professional love. Ten thousand feature flags, being checked at around 2 (or 200) million RPS from multiple deployments... I don't want to be the team with that as their side project. And once you're talking a t…

The scale is easy in practice, cause you outsource to a CDN. But everything takes time and has opportunity cost.

Re: It's OK to hardcode feature flags

#46

Post by 3eb7988a1663 »

dave4420 wrote: post #3

If 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(“…

That specific example feels like it might be ok? Presumably you have a very slow process by which customers are identified as VIP white-glove whales. Hard-coding the account representing X% of revenues is not going to experience a lot of churn. Just make it a collection variable, so you do not repeat yourself in multiple places.

Re: It's OK to hardcode feature flags

#47

Post by the_mitsuhiko »

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

The middle ground is a JSON file that is copied up and periodically refreshed. We (Sentry) moved from a managed software to just a YAML file with feature flags that is pushed to all containers.

The benefit of just changing a file is that you have a lot of freedom of how you deal with it (eg: leave comments) and you have the history of who flipped it and for which reason.

Re: It's OK to hardcode feature flags

#48

Post by maccard »

the_mitsuhiko wrote: post #47
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 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. The middle ground is a JSON file that is copied up and periodically refreshed. We (Sentry) moved from a managed software to just a YAML file with feature flags that is pushed to all containers…

How do you push the files to all of your containers? I’ve done this in the past with app specific endpoints but never found a solution I liked with containers.

Re: It's OK to hardcode feature flags

#49

Post by tnorgaard »

If I may make an suggestion: Instead of a static json file, read at boot, I'd suggest passing the feature flags down per request as a header, or a pointer to the set of feature flag. So that all systems for a given request, observe the same features. Just my 2 cents.

Re: It's OK to hardcode feature flags

#50

Post by thraxil »

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…

I would add two things:

It's often important that flag changes be atomic. Having subsequent requests get different flag values because they got routed to different backend nodes while a change is rolling out could cause some nasty bugs. A big part of the value of feature flags is to help avoid those kind of problems with rolling out config changes; if your flags implementation suffers from the same problem, it's not very useful.

Second, config changes are notorious as the cause of incidents. It's hard to "unit test" config changes to the production environment the same way you can with application code. Having people editing a config every time they want to change a flag setting (we're a tiny company and we change our flags multiple times per day) seems like a recipe for disaster.

Post reply on HN