9 ms·

The risk of feature flags is well illustrated by the downfall of Knight Capital Group: https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/ ht

• skissane 6y ago
  > The code that that was updated repurposed an old flag that was used to activate the Power Peg functionality A practice you can adopt which can prevent this: suppose you use JIRA (the practice works the same for any such system, I'm just using JIRA as an example), and for every new feature you must have a JIRA issue, e.g. FEAT-1234. Now you have the rule that the feature flag name must embed both (1) the year and quarter the feature was merged and (2) the JIRA issue. So as part of FEAT-1234 I create feature flag "2020q3-FEAT-1234-split-big-trades". And then you have a custom field in JIRA called "feature flag name", and you record "2020q3-FEAT-1234-split-big-trades" in that field for FEAT-1234. And then you need to have this as a standard check in processes such as code review and release management. It might even be useful to have a report which compares JIRA to the feature flag system to check this rule is being followed. If they'd adopted this practice, that particular bug would likely have been avoided. Adding a new feature, you would not be allowed to reuse an old feature flag from years ago, for the year and quarter and the JIRA ticket would all be different.