Application to Reclassify Feature Flag Archaeology
The engineer has located a feature flag with no documentation and cannot determine whether removing it is more dangerous than leaving it indefinitely.
I.
The flag is named enable_new_flow. It is set to false. It has been set to false for an indeterminate period. The engineer who set it to false is no longer at the company. The engineer who created it may be a different person. This is not confirmed.
II.
Searching the codebase for enable_new_flow returns forty-three results. The flag gates a code path that controls some aspect of an operation whose name suggests urgency. The code path itself is functional. It has tests. The tests pass. None of the tests clarify whether the path is supposed to be active in production.
III.
The engineer asks the team. Three people do not recognize the flag. One person says it sounds familiar. This person is asked to elaborate. The elaboration is: "I think someone mentioned it once."
IV.
The options are as follows. Delete the flag and enable the new flow, and discover whether "new" meant new in 2021 or new in a way that is dangerous today. Leave the flag at false forever and classify it as legacy infrastructure. Leave the flag at false and document it so the next engineer can inherit the same uncertainty.
Governing Rule: Under the applicable standard, any feature flag archaeology that restores service once may be reused until someone proves why it worked. Leaving the flag untouched is a form of this principle.
V.
The flag is left at false. A comment is added above it: # TODO: investigate this. The comment is now part of the codebase. The flag is safe.