It's OK to hardcode feature flags

Original Article ↗ Hacker News Discussion ↗

When Hardcoding Feature Flags Is Acceptable

  • Many see hardcoded / config-file flags as fine for:
    • Low-traffic apps, solo devs, or orgs with very fast and frequent deployments.
    • Trunk-based development where flags are short‑lived “merge shields” and later deleted.
    • Beta builds or QA/stakeholder test deployments.
  • For these cases, a JSON/YAML file or env vars, committed and deployed with the app, are considered sufficient.

Why Dynamic Feature Flags Matter

  • Strong agreement that in higher-scale or slower-deploy environments, hardcoding is risky:
    • Need to roll out gradually, target segments, and turn features off instantly without redeploy.
    • Critical for mobile and long release cycles where shipping another build is slow.
    • Flags de‑risk deployments, enabling safer experimentation, A/B testing, and measurement of impact (crashes, engagement, revenue).
  • Several commenters say their org effectively never rolls out without flags; disabling a broken feature via a flag has saved incidents.

Build vs Buy: Homegrown vs SaaS Platforms

  • Many argue feature flags are simple enough to roll yourself:
    • Flags in a DB table, JSON in object storage, YAML in a separate repo, etc.
    • Benefits: no extra outage dependency, avoid vendor lock‑in and high SaaS costs.
    • Some report moving from robust in‑house systems to LaunchDarkly increased outages and complexity.
  • Others defend SaaS tools:
    • Provide rule builders, targeting, analytics, experimentation, multi‑tenant support, SSO, auditing.
    • Can be worth it for mid‑to‑large SaaS orgs where a dedicated team would otherwise be needed.

Implementation Approaches & Operational Concerns

  • Patterns mentioned:
    • DB‑backed flags with per‑user overrides; local caching and/or CDN long‑polling.
    • Config files pushed via CI/CD, object storage, secret managers, or Kubernetes ConfigMaps.
    • Passing flags (or references) per request so all services see a consistent set.
  • Concerns: atomicity of changes across large fleets, minimizing latency, and ensuring apps keep working when external flag services fail (near caches, defaults, offline modes).

Pitfalls & Terminology

  • Common problems: stale flags never removed, tangled flag dependencies, config‑caused incidents, and confusing “flags vs config” semantics.
  • Some feel “feature flags” has drifted from its original “development guardrail” meaning into generic runtime configuration, reducing conceptual clarity.