Feature Toggles (aka Feature Flags)¶
Hodgson, P. (2017). Feature Toggles (aka Feature Flags). martinfowler.com.
Cited by¶
6 citations across 6 artifacts.
Each citation links to the sentence it supports in the citing article.
Mechanisms¶
- Deprecation with Rollback Window
- Instead of deleting it, they put the removal behind a feature flag
This sourceDescribes release toggles that ship alternative code paths and stage exposure independently of deployment.
- Instead of deleting it, they put the removal behind a feature flag
- Feature-Flag Disablement
- The classic failure mode is flag debt — long-lived flags that never get cleaned up, until the codebase is a maze of switches whose combinations no one has tested and whose "off" paths have quietly rotted, so the safety lever you reach for in an incident no longer does what you think.
This sourceExplains that proliferating, long-lived feature toggles create combinatorial testing complexity and should be removed proactively when no longer needed.
- The classic failure mode is flag debt — long-lived flags that never get cleaned up, until the codebase is a maze of switches whose combinations no one has tested and whose "off" paths have quietly rotted, so the safety lever you reach for in an incident no longer does what you think.
- Feature-Flag Experimentation
- It is the delivery half of progressive delivery, and its blast-radius discipline is what keeps continuous experimentation survivable.
This sourceShows that feature flags can expose a change to selected users rather than the entire population.
- It is the delivery half of progressive delivery, and its blast-radius discipline is what keeps continuous experimentation survivable.
- Feature-Flag Graduation Review
- Its characteristic failure is feature-flag debt — flags that graduate but are never cleaned up, so the codebase silently accumulates dead switches and permanent conditional complexity that outlives the decisions that created them.
This sourceWarns that feature toggles multiply, add conditional logic and testing burden, and should be removed proactively when no longer needed.
- Its characteristic failure is feature-flag debt — flags that graduate but are never cleaned up, so the codebase silently accumulates dead switches and permanent conditional complexity that outlives the decisions that created them.
- Feature-Flag Release
- Its failure modes follow from the same machinery — stale flags pile up into flag debt, a combinatorial tangle of untested toggle states, and a canary
This sourceDocuments the carrying cost of accumulated feature toggles and the combinatorial explosion of possible toggle states that cannot all be tested.
- Its failure modes follow from the same machinery — stale flags pile up into flag debt, a combinatorial tangle of untested toggle states, and a canary
- Reversibility Tag or Feature Flag
- A feature toggle lets a team try a refinement under real conditions and unwind it on evidence
This sourceShows feature flags supporting production experiments and canary releases while preserving the ability to disable a feature quickly when evidence reveals adverse effects.
- A feature toggle lets a team try a refinement under real conditions and unwind it on evidence
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 6 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:b747d1624898 · see in the full table