Improving feature flag implementation to achieve flow
summary
Feature flags are often misapplied and create invasive if/else clutter, hidden dependencies and extra on/off test permutations; a French survey finds 29% of flags never change within an iteration, 27% are for segmented activation, 40% support parallel dev and 10% enable testing directly in production. Viable replacements include trunk-based development with smaller user stories (example: healthcare booking split to deliver start/end flows), design patterns like branch-by-abstraction or strangler for rewrites, using domain events or strategy/ decorator for context activation, and circuit breakers + health checks to automate toggles and fallbacks.
AI-written summary · about
chapters (15)
- 0:00Introduction and context
- 2:07Problem with feature flags today
- 7:35What is a feature flag
- 9:49Why use feature flags
- 14:21Alternatives to classic flags
- 17:36Trunk based development limits
- 20:12Splitting user stories properly
- 23:52Hamburger technique for splitting
- 27:34Context specific activation
- 30:01Complex use cases and patterns
- 32:30Two versions in parallel
- 35:47External dependency handling
- 38:17Explicit customer requests
- 38:40Long-term drawbacks of flags
- 40:31Final recommendations and Q&A
related talks
56mWhen Feature flags go bad
08mThe Art of Feature Flagging
30mA Tale of Two Feature Flags
11mFeature flag use cases you haven't heard about yet
06mFeature Flag Foul-ups
44mFlags of Flexibility - Unlocking Rapid Iteration
19mBeyond the Toggle: Feature Flags as Your Migration Safety Net
59mFaster & less risky releases with feature flags