I don't know if I'd classify the cleaner diagram as "cheating" per se, but it does trade one kind of complexity for another kind. Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance. Sometimes systems have good reason to be complex, and sometimes we have good reasons to hide much of that complexity, but let's not conflate hidden complexity with the lack of complexity.
If I were to suggest a way to make the original chart cleaner without changing the quantity of explicit nodes and branches, I would start by reducing it into parts that are cyclic and parts that are acyclic, then drawing clear divisions between those parts. Then you could give these encapsulated bits names and thereby make it easier for them to refer to each other (such as in the duplicated flows between local and global preferences) without having to draw a mess of crisscrossing lines.
I agree with you; it is hand-wavey and strays into "spherical cows in a vacuum" territory. Practical for discussions, not so great for implementations, where details matter greatly. I would presume the original diagram was meant to align on the specifics; the revised version from the author leaves much to interpretation.
>Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance.
It kind of does though, because it's easier to understand what the system does in general without necessarily wanting/needing all the lower level detail.
That's also one of the reasons we use functions, instead of unrolling everything into a big ball of code, no?
That’s not reducing complexity at all though, just hiding it…
Which is fine for someone working a job that doesn’t need to understand all the stuff behind the curtain, but not fine for anyone who actually wants to understand the overall system.
>That’s not reducing complexity at all though, just hiding it…
It's a representation. The actual thing will still have the whole complexity.
What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.
People looking at flowcharts usually don't need the entirety. Especially as the flowchart could even be out of date, or miss some of the code-level subleties.
Why would those seeking to grasp the entirety use a less efficient and more cumbersome method, than just looking at the full flowchart in the first place? (assuming it exists)
And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
Because the code is the entirety of the process. Any graph can be wrong, but the code cannot, because it is the implementation.
The purpose of a graph is to allow the visualization of the process in an understandable manner. If it doesn't abstract away much from the code, you might as well look at the code directly
Code is not always the same as the process or what the machine actually does... There are hundreds of posible factors from bitflips to a cable getting loose in a socket that could change either.
e.g. There clearly can be a computer configured with enough memory and dense enough memory that at least one bitflip is practically guaranteed in a certain unit time, so the actual process has to include that.
So the code is an abstraction just like the flowchart.
>Code is not always the same as the process or what the machine actually does...
You started with why aren't they "just looking at the full flowchart [to understand the entirety]".
And the parent wrote that because the flowchart is not the entirety, the code is.
Do you think this retort you make above is refuting the parent's point? If anything, it expands it, going further against your original point: that's why they're not just looking at the full flowchart.
And, yes, "code is an abstraction, just like the flowchart", but code is the abstraction the programmer controls and tries to summarize and understand. The flowchart is a higher level abstraction of an abstraction.
>Are you confused about the meaning of understanding vs a literal equivalence?
No, but you seem to be about any context not spelled out completely and pedantically.
>e.g. “ Because the code is the entirety of the process” is clearly false regardless of which way you look at it.
A coder works on code (literally editing lines of code, which is what they deliver), and is called to create, understand, and debug code.
Else, sure, code also runs on some server, by some organization, that had meetings to decide the requirements, and there are also end users, and the whole thing runs in some planet, inside a universe, or perhaps a multi-verse, so the code its not the entirety of the process /s
You have processes more formal and thorough than their code implementation? Really?
At the end of the day, is it the cover-every-possible-bitflip-and-gamma-ray-bursts process that produces results out of thin air, or is it the machine running the code?
> Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance.
The original diagram does this too - it has an "A && B" node.
From my perspective simple boolean means a single known value stored in one variable. I suspect the underlying code performs a number of calculations for each one of the flow chart "booleans". Of course, maybe that points to a design flaw and there should be a single policy instance that aggregates all of the variables into one place.
I just turn off notifications completely. Horribly implemented notification systems have completely turned me away.
DnD on? Nope still get notified. Government sends Amber alert? Yea let’s full send it across the entire state for a crack head vs police incident that occurred 500 miles away at 4AM.
Severe weather alerts have now been moved to voice calls and that number whitelisted in my contacts
Same, my phone was gradually turning into another point of control over me, rather than the other way around and it being a tool to help me. Only a handful of people are default allowed through DnD, all of the nonsense government alerts are off, almost all app notifications are off save for absolutely the most important ones. If an app somehow breaks through after all of that, it's an instant uninstall, I just don't want to waste any more of my life than I alerady have being subservient to this shit. It's a daily annoyance to have to dismiss popups in apps when they notice they can no longer send notifications. Almost as annoying as the notifications themselves.
Most work apps have a permanent 'Away' status and a message on and the expectation set that I sparingly check throughout the day. It works really well, my mind has never been quieter and more at ease.
Maybe the real source of complexity in that flowchart is there are just too many ways to suppress notifications. You have muting, do not disturb, do not disturb overrides, @message preferences per channel and global, DM preferences, and so on.
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?
"Feature flag" development culture is in direct conflict with user's having intuitive, consistent experiences that they can model in their head.
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.
Feature flag development culture is the only practical way to do continuous delivery. The old approach is still used in markets where it makes sense - database systems, for example, often have only a handful of releases per year. But there's a lot of markets where it's just not feasible to make customers wait 3-6 months between when you finish developing a feature and when it's available for use.
> Feature flag development culture is the only practical way to do continuous delivery.
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.
Maybe Continuous Delivery is the problem. What are these markets where customers want such frequent changes? As a user, I don't really want my software changing daily, weekly or even monthly. I don't want features to come and go depending on which arm of an A/B test I am in. I don't want to be part of the developer's "experiment" and metrics-gathering.
The actual need for continously delivery is mostly related to running public-facing services at large scale that need the ability to adjust to external events quickly, e.g. when defending against a new form of abuse requires an immediate software change.
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.
Engineering is about making certain that stuff works before it enters production. If we claim to do software engineering, then that's just a simple part of doing our job. Everything else is just tinkering and hacking (the bad kind).
From an engineering point of view, yes. But not from the business point of view.
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.
That whole approach is so disrespectful of users. If you are a serious business, then hire sufficient QA people, and empower them to do their job.
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.)
Agreed. Speaking as a user, I much preferred when the industry in general had a slower release cadence. I want to update once every year at most, and usually I want to update less frequently than that. Continuous delivery is a thorn in my side.
No individual customer wants frequent changes. They want changes they care about ASAP and changes they don't care about never. But unless I'm maintaining per-customer versions (which can make sense for high value enterprise customers!), promising user X that I won't make any changes until January necessarily means telling user Y that I refuse to resolve their showstopping bug report until January.
A separate gripe: Still no support for "batching up" a trickle of notifications from a particular DM/channel, which is especially frustrating on the phone-app.
*bzzzt* You probably met him, that one guy
*bzzzt* who sends messages like this
*bzzzt* and each time your phone vibrates for attention
*bzzzt* but you never needed to know that soon anyway.
I wonder if anyone's done a study on those different styles, clustering them with other things like type of work or personality traits.
I anecdotally associate "those people" with either:
1. Job roles (e.g. Sales) or personalities that are accustomed to interactively pushing people to do things for them
2. People who don't feel safe assuming that I can/will help.
3. Someone struggling to describe their problem up front, so they aren't sure what to place in my metaphorical inbox
4. There are multiple people they could reach out to for help, and they're trying to determine which person might react soonest. (But they aren't using other strategies like posting their problem in a channel and @-mentioning multiple potential helpers.) Their problem may or may not merit the kind of latency they're looking for.
I can’t work with notifications enabled. Every hour I work, I make a 15 min pause or so and then I check Slack and answer if needed.
Not just Slack, I don’t have any notifications enabled. I always pull. The only exception is phone calls.
I wish I could do that but rarely I do get something that needs my attention immediately because I don multiple hats including Infrastructure,SRE,DevOps,SysOps,programmer etc.
I have a second channel for urgent things, which is a phone call. I've told everyone that I'm available whenever, but they need to pick up the phone and call me. Surprisingly that little bit of friction seems to downgrade issues from 'urgent' to 'we can fix it tomorrow'
The issue is that sometimes something comes up that I can choose to quickly address and get folks going again. Adding that friction causes waste of time.
Every time I see this flowchart I get reminded that Slack casually sends half of my notifications to a sleeping/disabled laptop instead of my phone.
I also get reminded that Telegram has one of the simplest notification schemes in existence.
Notify last used device -> If still unread after ~30 seconds notify every logged in device. That's it, dead simple, never missed a TG notification.
Lol I rarely received notifications that I expect to. (I've checked my settings and done nothing else to fix it, not tried reproducing behavior nor reporting it to Slack.)
Paid server.
Android client.
Lightly used, in part due to the absence of notifications.
It's been over a year that I've missed notifications. More than 50% missed, comments to my threads especially, and also new messages on watched channels.
Flowcharts tend to suck when trying to describe anything remotely complicated. I doubt anyone is seriously using the original flowchart to get any work done, the actual code must be more readable, and would be guaranteed to be correct.
On the other hand, overloading a flowchart with things like "unless" or "including" makes it harder to follow.
That flowchart is absolutely what happens when a bunch of programmers got told to "draw the complete system" in one diagram - which is absolutely not how it should've been represented.
I will invest that time later. In anticipation, thanks.
I came here to see if anyone was talking about state machines that generate their own flowcharts, or codegen from flowcharts. I'd like to know if there's prior art.
It would be great for user acceptance. I'm minded to have a go myself, possibly with mermaid as an intermediate description. Stupid? Non-stupid?
I look at the first flowchart and think to myself, were all the product managers, business analysts, and UX designers drunk when all of that was getting implemented?
No. People just interact with these messaging systems in a variety of ways and the notification flow here has to account for that. Each sender might use @s and threads differently and then the recipients might have different tolerances for what they end up seeing notifications for. If you provide fewer options for the recipients, it's far more likely they'll just blanket disable notifications.
guys I simplified it to a single node in a flowchart, this is even simpler right?
(user not DND || message DND override) && ((message in thread && user in thread && user threads_everything) || ((channel notifications everything || (channel notifications unset && global notifications everything)) && ((message not in thread || user in thread) || (message has @channel || (message has @here && user is active)) && @channel messages not muted) || message contains @mention || message contains highlight word || message is on file owned by user))
Maybe Slack should stop making an LLM for data mining and chatbots, and instead, deploy an LLM to read a message and determine whether or not you should be notified, because notifications from Slack truly suck.
This specific problem is better solved by decomposing the logic into rules that tell when not to send a message. I refactored this diagram once that way, so it becomes absolutely straightforward.
That flow chart is crazy. It would be quicker to consider and think about every instance on a case by case basis rather than consult that chart. Snark aside, I do think the flowchart could be useful for the QA team to verify, approve, or disapprove of decisions made by the implementation team.
The most important thing to me about the original diagram is that it is underspecified-- you can't determine its meaning just by reading it and also having a basic knowledge of Slack. To understand it you need a close and detailed knowledge of Slack UI and behavior that I don't believe has been officially documented. In fact, I'm left with questions about this diagram I can't answer even after experimenting with Slack.
In other words, there is important tacit knowledge required to interpret the logic.
I wonder if there is an updated version of this available anywhere?
That complexity in the flow chart is probably just straight bugs, like TFA gets into. For example, I'm sure the flow chart — if you made one — for message "parsing" would be similarly complex. And it shows, on the client, since it feels less like there's a parser, and more like someone has cobbled a bunch of regexes together. There's a number of rather trivial to discover bugs¹, particularly around code block formatting and hyperlinks. That Slack will actively mutates entered text is doubly infuriating.
Similarly, complex flowcharts aren't necessarily something to be proud of, rather, something to be eyed with suspicion. Is that complexity essential complexity, or accidental complexity?
(Though sometimes it can be infuriatingly difficult to simplify. I've attacked a few such codepaths in my career only to come out going "nope, it's just that terrible/complex.")
On notifications, one of the best things I ever set up was making my name a notification trigger. Lets me know when people are talking about me (or even to me), but aren't using a @- tag. Some people just … don't seem to know how to do it?
¹trivial enough that it leaves me wondering: does Slack's own eng use Slack, with cognitive awareness of the things that they run into?
> That Slack will actively mutates entered text is doubly infuriating.
Slack is not good with that but man what are the people smoking that designed MS Teams? What the actual fuck happens when you try to type, copy, paste or send a message?!
For anything remotely complex flowcharts tent to break down for me, I prefer pseudocode for describing algorithms. But the article makes a very good observation about complexity.
I had to turn off my Dark Reader to light mode to see it. Yes, this is a very elegant, easy on the eyes and fun to read website/blog. I would like to use this theme unless it is a fully custom site.
If I were to suggest a way to make the original chart cleaner without changing the quantity of explicit nodes and branches, I would start by reducing it into parts that are cyclic and parts that are acyclic, then drawing clear divisions between those parts. Then you could give these encapsulated bits names and thereby make it easier for them to refer to each other (such as in the duplicated flows between local and global preferences) without having to draw a mess of crisscrossing lines.
reply