As I’ll reveal shortly, badly managed flags have caused huge outages, a mountain of tech debt and, on one infamous occasion, almost bankrupted a company.
Complexity creates confusion. Embedded and interlinked flags create many potential states that can quickly become untestable and unpredictable.
Poor maintainability creates tech debt. Old “zombie” flags get reused in unintended ways, or negatively react with new changes.
In this issue, I’m going to share how you can avoid these problems, so you can enjoy the benefits of feature flags in peace.
This might break our tests if we expected the price to be a specific number, or always be above zero. Every test would need to handle the newly added absolute discount.
With this, each pricing strategy can have its own set of tests, and there are fewer states to worry about for the calculatePrice function. When we want to change or add a pricing strategy, we don’t need to worry about it affecting the others.
Ideally, use flags in as few places as possible and abstract as much as possible behind a single flag. This creates a clear separation and isolation of flag-related code, which limits complexity and improves maintainability.