Principles for building and scaling feature flag systems
> Make feature flags short-lived. Do not confuse flags with application configuration.<p>This is my current battle.<p>I introduced feature flags to the team as a means to separate deployment from launch of new features. For the sake of getting it working and used, I made the mis-step of backing the flags with config files with the intent to get Launch Darkly or Unleash working ASAP instead to replace them.<p>Then another dev decided that these Feature Flags look like a great way to implement permanent application configs for different subsets of entities in our system. In fact, he evangelized it in his design for a major new project (I was not invited to the review).<p>Now I have to stand back and watch as the feature flags are being used for long-term configurations. I objected when I saw the misuse- in a code review I said "hey that's not what these are for"- and was overruled by management. This is the design, there's no time to update it, I'm sure we can fix it later, someday.<p>Lesson learned: make it very hard to misuse meta-features like feature flags, or someone will use them to get their stuff done faster.