Conversely, feature flags can create annoying issues due to compliance requirements.
I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.
Right, they add risk both in terms of inadvertently being turned on / off and also in terms of permutations of possible system configurations that need to be tested. Less of a problem for well engineered systems with good deployment practices but it’s rare to come across these mythical things. :)
It depends a lot on the domain. I've mostly worked in high compliance/regulation worlds. It can be kind of stifling, honestly, but "oops maybe we had the feature flag turned on" is not going to cut the mustard.
Most startups can ignore all that at least until they get to a scale where "run out of money, go bust" is not the biggest risk to their business :)
This is very true and is exactly why there is no magic right answer other than “it depends”.
There are different stages of company lifecycle, different industries, different regulatory environments etc.
The processes put in place always have a cost - if picked appropriately it is worth paying, otherwise it is a waste that can hurt or even kills a project. This balance is the “art” of the job that I personally am only starting to probe around at my level and so it is still quite interesting. :)
I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.
They're useful, but not necessarily simple.