I love dials and knobs and sliders in my software, but at some point when they are all for the same feature, there is no longer any way for the user to intuit how they interact.
Does the complicated flowchart point to deficiencies in the Slack user interface? If the user cannot intuit the flowchart, then how can they (as several sibling comments rightly point out) reliably turn notifications on or off?
Algorithmic transparency should be a thing, no?
If the vendor needs a database report to see what features the user may encounter in any given session, because it's an n-dimensional matrix that changes based on uncountably many factors, there is no mental modeling to be done. The user just experiences some idiosyncratic amalgam of code in each session, and the vendor watches aggregate metrics to make sure the number of users in immediate crisis remains below some threshold -- bringing in a $XXXX/hr on-call team to identify and apply some adequately impactful change if it breaks over. Meanwhile, the users-in-crisis cross their fingers that the next time they open the app, they get a better roll on the feature matrix and encounter a more tolerable subset of issues.
If you want to be able to understand your software and know how to turn things on and off, you need to demand a whole new (old) approach to building and publishing things. We're way off track right now.
1. That's not true. Even with continuous delivery, you can still just have a sane and mostly stable roadmap that you're betting on, and gradually migrate all your users along it in a cohesive way with thoughtful transitions when any radical changes are needed. Feature flag stuff is a specific approach to product design that took over a lot of engineering teams in the last 15 years. It relies on continuous delivery, for the most part, but continuous delivery is itself completely ambivalent to it.
2. Continuous delivery is rarely necessary in the first place, and almost never in the interest of users. It gained ubiquity as it became first became practical and coincided with product designer's naive enthusiasm for feature flags, but mostly works against user satisfaction by making it hard for users rely on their tools being in a specific condition at any time.
Al other software could get away with deliberate release cycles rather than an urge to YOLO things into production. I just think that there is a fallacy in business leadership that ultra short turnaround times on features actually matter for a business.
It's like a restaurant. You can make sure they new dish tastes like what you intended and isn't going to poison anyone, but until it's on the menu you don't really know if people will want to eat it or if it will be a success for the business.
This does make me wonder whether there's a place for a system where you split your usebase into N shards, and only deploy new versions to one of them; reducing the update rate from a user perspective by a factor of N. Of course, this means you have to maintain compatibility with N versions, but that's still better than N feature flags.
Expecting your customers to do your QA for you is super common these days. But that doesn't make it right.
(What really infuriates me is the general lack of feedback channels that enable users to actually contribute to QA. With open source software, end users can at least open a ticket on the bug tracker. If it's a commercial product, all too often the only point of contact is a disempowered call-centre worker, who can't even log a bug for you.)
It can decrease the chances but isn't a panecea.
Sometimes @channel is important, because everyone in the channel knows to use it sparingly.
Sometimes one person just constantly spams @channel in every message.
So you do need different settings.
So you need the nuance to deal with the nuance of people.