I agreed. My perspective is that there are two kinds of feature flags: temporary and permanent.
Temporary ones can be used to power experiments or just help you get to GA and then can be removed.
Permanent ones can be configs that serve multiple variations (e.g. values for rate limits), but they can also be simple booleans that manage long term entitlements for customers (like pricing tiers, regional product settings, etc.)
Interesting question. Feels like they could maybe do this effectively for a significant portion of the population but that more savvy users would find ways around a blockade?
It would help to live near the northern border - one could get cell signal from "the other side" in certain situations and effectively restore a limited connection to a limited area.
Recently worked at a mid-sized learning technology company. Feature flags were transformative for our product delivery to fully decouple deploys from releases, reduce risk, and offer tons of control over feature rollouts. Really can't imagine releasing without them.
In my new role, I'm curious what teams do with feature flags post-release. Do you have a good process for cleaning them up? Do they have long term usefulness as a failsafe or for customer/user configuration? Is it really an issue if they just stay in the code forever? Does this cause issues for you?
Sounds like a product manager didn't properly define the acceptance criteria for the validation on their name fields. Name validations often tend to be overly strict and, in some cases, slightly racist/ethnocentric.
