Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
Ah that reminds me, I should write about the tech and product benefits of having feature flags and abtests.
The downside is complexity, a lot. Each new flag will add an exponential complexity on all related non exclusive features, ex
One button, 2 positions, 2 colors
Color A in position X
A in Y
B in X
B in Y
If you add a shade color the number of possible user experiences triples (no shade, shade A, shade B). This means double the testing, metrics ...
So do not abuse this function, clear the not used flags as fast as possible.
Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
I kind already talked about them, but only from the A/B tests perspective. There are a lot of other good usages for flags, like soft rollouts/releases, dual writes and so on.
Ah that reminds me, I should write about the tech and product benefits of having feature flags and abtests.
The downside is complexity, a lot. Each new flag will add an exponential complexity on all related non exclusive features, ex
One button, 2 positions, 2 colors
So do not abuse this function, clear the not used flags as fast as possible.
Awesome I'll be sure to read it if you post it on here!
Yeah totally agree with this, would only use the config side (colours etc) on something meaningful.
Also, I tend to slowly remove flags as they become more stable/mature. Having stagnant flags is definitely something to avoid.
I kind already talked about them, but only from the A/B tests perspective. There are a lot of other good usages for flags, like soft rollouts/releases, dual writes and so on.
Yeah totally, I was genuinely surprised how using them totally changed my dev experience at times especially being able to do smaller releases