Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other.
Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1].
For example:
# Feature flag — variant gate for rollout
flag = sdk.check_gate(user, "checkout_flow")
if flag == 'open':
render_new_checkout()
elif flag == 'warning':
render_warning_checkout()
else:
render_old_checkout()
# Raw remote config pulled — structured values for tuning behavior
config = sdk.get_config(user, "checkout_settings") # if the config changes based on user or context, this "remote" config is considered "dynamic"
timeout_ms = config.get("timeout_ms", 5000)
max_items = config.get("max_items", 50)
allowed_tlds = config.get("allowed_tlds", [".com", ".org"])
In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website.
As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags.
One small edit: many also look to the Internet to meet their needs, beyond just fantasy or desire. Their lashing out comes after the disappointment: when the internet simply cannot fill the hole in them the way the common goods once did.
Humane, as a secular and universally applied sentiment, is a bit of a modern idea, once backed by common goods; shared institutions, third places, extended families, good economy, religion, etc. With those common goods fading, I see people more and more lashing out against each other; particularly in a frictionless environ that incites/outlets fantasy desires. The war of all against all from the safety of our screens; at least for the growing numbers who live their lives on the upper-case Internet.
Lower-case internet is ok as a tool for making spaces. But I reckon humane-ness, or really, virtue, is a habit built from within. And the habits the Internet rewards are generally the wrong ones.
Statsig's core value is their experimentation platform— the automation of Data Science.
Big Tech teams want to ship features fast, but measuring impact is messy. It usually requires experiments and traditionally every experiment needed one Data Scientist (DS) to ensure statistical validity, i.e., "can we trust these numbers?". Ensuring validity means DS has to perform multiple repetitive but specialized tasks throughout the experiment process: debugging bad experiment setups, navigating legacy infra, generating & emailing graphs, compensating for errors and biases in post-analysis, etc. It's a slog for folks involved. Even then, cases still arise where Team A reports wonderful results & ships their feature while unknowingly tanking Team B's revenue— a situation discovered only months later when a DS is tasked to trace the cause.
Experimentation platforms like Statsig exist to lower the high cost of experimenting. To show a feature's potential impact before shipping, while reducing frustrations along the way. Most platforms will eliminate common statistical errors or issues at each stage of the experiment process, with appropriate controls for each user role. Engs setup experiments via SDK/UI with nudges and warnings for misconfigurations. DS can focus on higher-value work like metric design. PMs view shared dashboards and get automatic coordination emails with other teams if their feature is seen as breaking. People still fight but earlier on and in the same "room" with fewer questions about what's real versus what's noise.
Separating real results from random noise is the meaning of "statsig" / "statistically significant". I think it's similar to how companies define their own metrics (their sense of reality) while the platform manages the underlying statistical and data complexity. The ideal outcome is less DS needed, less crufty tooling to work around, less statistics learning, and crucially, more trust & shared oversight. But it comes at considerable, unsaid cost as well.
Is Statsig worth $1B to OpenAI? Maybe. There's an art & science to product development, and Facebook's experimentation platform was central to their science. But it could be premature. I personally think experimentation as an ideology best fits optimization spaces that previously achieved strong product-market fit ages ago. However, it's been years since I've worked in the "Experimentation" domain. I've glossed over a few key details in my answer and anyone is welcome to correct me.
Hats off to Statsig. They built a stellar product. Superior to many of their industry competitors like Optimizely. Back when I was on an internal Experimentation platform, we were impressed how they balanced dev velocity & stat rigor https://www.statsig.com/updates These guys ship.
Business-wise, I think getting acquired was the right choice. Experimentation is too small & treacherous to build a great business, and the broader Product Analytics space is also overcrowded. Amplitude (YC 2012), to date, only has a 1.4B market cap.
Joining the hottest name next door gives Statsig a lot more room to explore. I look forward to their evolution.
Off-topic, irrelevant question: does anyone need a local first version of Airtable? That uses SQLite under-the-hood and plugs into files and data with syncing across computers.
I’m curious (as a solo dev) if there’s a market for such a product.
When a company does not want to pay (or empower) a principal engineer, they hire legions of junior engineers to cover up the gap. People who focus on the joy of shipping than on the pesky questions of "shipping what?" and "who will maintain it?"
Many of us here owe our jobs to the deliberate weakening of technical authority and expertise. That debt probably blinds us to those management decisions, and the need for architects to balance them out.
I didn't see self-marketing in their words. Rather, I read a promise:
> The founder of SQLite and all current developers have pledged to follow the spirit of The Rule to the best of their ability. They view The Rule as their promise to all SQLite users of how the developers are expected to behave. This is a one-way promise, or covenant. In other words, the developers are saying: "We will treat you this way regardless of how you treat us."
So far as I've seen, SQLite's developers have lived up to their words. They practice what they preach, while most other software communities do not. Rather, most of the popular ones align with your insinuation: pseudo-religious values and holier-than-thou attitudes cloaking misbehavior.
A few too many principles mixing the BDFL & their project, I think. It's ok for a BDFL to share the things they care for, but I would prefer a harder framework for predicting BDFL behavior.
> While Clarke's story ended with the priest in despair after the revelation that the alien civilization had perished in order to light "the Christmas star," the TV episode added an epitaph by the aliens, revealing their acceptance of their place in the universe. Brennert later commented that "Over the years I've taken a little bit of heat from certain fans in the science fiction community for changing the ending of this story. I actually maintain that the ending as it is in this episode is implicit in the story and is not really at odds with the kind of metaphysical work that Clarke did in Childhood's End."[1]
The missing word from this conversation is "duty": a moral obligation to others.
People pretend rights can exists without duties because, like you said, they're trying to get good things for free. They're asking for work from others and not being upfront on the price of the work. I say "I have a right to good service at the DMV", because I can't say the DMV must give me, let alone everyone, good service. In a larger view[1], a language of rights without duties undermines the broader social contract, confuses conversations with indirect terms[2], and provides the selfish with the illusion of care for their fellow man.
As it so happens, the original declaration of human rights[2] specifically calls out the necessary union of duties and rights. However, the UN declaration does not do so, likely because no one, bar a few western countries, actually had the power to enforce those rights on a global scale. Hannah Arendt commented on this topic at length, though it's hard for hyper-individualists to digest[4].
Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1].
For example:
In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website.
As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags.
[1] https://engineering.atspotify.com/2020/10/spotifys-new-exper...
[2] https://docs.statsig.com/dynamic-config/overview https://blog.x.com/engineering/en_us/topics/infrastructure/2...