FM3 — Unbounded Resource Consumption
The failure mode is not in building truth tables. It is in expecting exhaustive truth-table testing to scale.
Consider a function with a boolean gate for each feature flag in a production system. Large systems have dozens of feature flags. 40 feature flags → 2⁴⁰ ≈ 1 trillion combinations. A test suite attempting to cover the full truth table would require terabytes of test data and years of runtime.
The symptom: a CI pipeline that grows slower with every new feature flag. Each flag doubles the number of theoretically-required test cases. Teams respond by testing less — fewer combinations per flag — which is the correct tradeoff when made explicitly. It is FM3 when the team does not realize they are making it and simply runs out of capacity.
The structural fix is to minimize interaction between feature flags. If two flags are fully independent — one governs the payment flow, the other governs the notification system — they do not interact in the truth table. You can test each independently: 2¹ + 2¹ = 4 tests instead of 2² = 4. Wait, that is the same. For 3 independent flags: 3 × 2 = 6 tests instead of 2³ = 8. The saving grows: 40 independent flags require 80 tests instead of 10¹².
Independence is the key. When flags interact, the combination space grows. When they are independent, it collapses. Designing feature flags to be independent — to avoid shared mutable state and shared decision points — is a concrete engineering technique to prevent FM3 in test suites.