A flag lets you ship the code dark and turn the behaviour on for one account. It is not a substitute for a finished design.
One flag, one behaviour
Name the flag after the behaviour, not after the ticket. Default it off in production and on in tests so the new path is actually exercised. Remove the flag when the behaviour is the only behaviour, or the code will carry two products forever.
Flags that touch money
A payment flag should be per account, and the invoice should record which path created it. Turning a flag off must not orphan a payment that already left for the provider. Write that rule next to the flag.
Who can flip it
An operator needs a screen or a documented command, not a redeploy, if the point of the flag is speed. Log the person, the time, and the account. A flag nobody can see is a surprise waiting in a settings file.
A flag with an owner and an end
A flag is a way to ship the code dark and turn the behaviour on for one account. Name the owner and the date you will delete it. A flag without a delete date becomes a second configuration language that nobody can test.
Read the flag at the edge of the feature, not in twenty templates. Default it off. Log when a request takes the new path so you can see that the one account you enabled is the account that is actually running it.
What to do this week
- Default new behaviour off in production.
- Record the flag on any payment it affects.
- Delete the flag in the release after it is universal.