Feature Toggles: The Good, The Bad and The Ugly
summary
A catastrophic reuse of a flag at a high‑frequency firm causes an infinite loop across 7 of 8 servers, racks up ~$450M in 45 minutes and ends the company; lesson: don't reuse toggles. Large firmware codebases move from compile‑time ifdefs to per‑model startup configs and cut feedback from eight weeks to two days. A phased rollout of an email sender uses RabbitMQ, a single‑user tester, then two queues to fix mail‑merge overload and finally deletes the toggle. Rules: name toggles specifically, keep lifespans short and monitor queries; use trunk‑based development.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:53Knight
- 7:14NEVER Reuse A Toggle
- 7:59Name Toggles Well
- 9:43Keep Lifespan Short
- 16:06Trunk Based Development
- 18:07Architecture Matters
- 27:08Branch By Abstraction
- 35:53Complexity
- 39:13Testing is harder
related talks
35mFeature Toggles: The Good, The Bad, and The Ugly
30mFeature toggles: ask us anything
36mIt's More Than Feature Toggles: ...
18mTrunk Based Development and Feature Toggles
20mFeature Flag-Driven Development… in Reverse
01h 09mFeature flags: the toggle, the A/B test and the canary
19mBeyond the Toggle: Feature Flags as Your Migration Safety Net
51mFeature Toggles, or How to Deploy Features Without a Release