When Feature flags go bad
summary
Feature flags let code be toggled live for kill switch emergency stops, percent rollouts and geography/IP targeting, and early access tied to metrics like NPS >50; they can also be used for entitlement tiers. Mismanagement causes real damage: an undocumented flag triggers high‑frequency trades and loses about $500M in ~20 minutes and takes hours to diagnose; another flag breaks uploads and costs ~4 hours to find. Best practices are strong naming linked to JIRA, locked permissions and audit trails, a three-month rule to remove stale flags and explicit cleanup to avoid leftover flags.
AI-written summary · about
chapters (33)
- 0:00Intro
- 1:48The world is changing
- 9:42Im ready for your patients
- 10:26Early access and blocking
- 11:50Late access and blocking
- 12:40Night Capital
- 14:40Naming conventions
- 16:39Overused flags
- 19:20Conflicting flags
- 21:34Do not ever push
- 23:58Leftover flags
- 26:47How to feature flags successfully
- 32:16Do people have questions
- 32:28Temporary vs permanent flags
- 33:20The 3month rule
- 36:21Highlevel features
- 37:30Is it dependent on architecture
- 38:36Questions
- 39:08Future flags
- 40:17Defaults
- 41:07Testing
- 42:37Fear
- 43:58Quota
- 44:15Feature flags
- 44:55API
- 46:31The real benefit
- 47:12Find the right rhythm
- 48:11Best practice
- 48:55What if they dont like it
- 51:05Feature flags vs featured branches
- 52:22Getting comfortable with feature flags
- 53:25Config vs feature flags
- 54:49WebSocket SDK
related talks
40mWhen Feature flags go bad
06mFeature Flag Foul-ups
30mA Tale of Two Feature Flags
11mFeature flag use cases you haven't heard about yet
59mFaster & less risky releases with feature flags
41mImproving feature flag implementation to achieve flow
08mThe Art of Feature Flagging
19mBeyond the Toggle: Feature Flags as Your Migration Safety Net