5 ms·

It's a pretty common use of toggles, really! It has many upsides: decoupling deployment of code from feature release (useful for many reasons eg giving PMs cont

It's a pretty common use of toggles, really! It has many upsides: decoupling deployment of code from feature release (useful for many reasons eg giving PMs control over the feature release), gradual feature rollouts, fast feature rollbacks, breaking up big features over multiple small PRs (eg each implementing a different part of the logic/UI), deploying "risky" code knowing you can enable/disable it instantly... We use this extensively at work, and wouldn't go back. You call it "just hiding incomplete parts of a feature", but for us that was a huge improvement in workflow. The real downside is that these flags tend to outlive their purpose; they don't get cleaned up as soon as they should.

doabitnormalman 3y ago
I would like to introduce feature toggles at my place of work as well, but I'm worried we will get massive amounts of if-statements everywhere. Is there a smart way of implementing (many) feature toggles?
jacknews 3y ago
Yes I agree about staged rollouts, ability to 'unrelease' features, and so on. But let's say you're part way through implemeting a new feature, and you need to alter a db table. How do you know that won't affect existing code (apart from tests)? How do you put that behind a feature flag anyway? As I said, deploying a change like this, without it being used for anything, seems like all risk and no gain.