This is a luxury if you as a dev get handed something like this. If you're actually the one that has to make the flowchart by translating customer requests, it's clearly a lot harder.

All hail the product people that have to do this.

In my experience, virtually none of the product people do this, at least initially. The requirement to begin with covers about 10% of this flowchart, then engineers start asking questions about edge cases, and pretty soon you’re sitting through your third meeting trying to just get everyone on the same page of what the requirements are, let alone how to build it.

You missed the part where you ship it with the 10% covered and then those "edge cases" get reported by pissed off customers who keep getting alerted despite their notification preferences.

Not to mention these notifications cross multiple devices so depending on how the teams are split there might be totally different teams managing the frontend toggles to change them and the backend services that persist those toggles... and then maybe a team or two to actually handle the sending.

Maybe another team that's just dealing with the WebSockets - gotta get notified about new messages if you have the app open, too.

Same here. I guess this is the ethos of Agile? Start somewhere and iterate on requirements/edge cases as they're needed/arise?

Though I kind of hate this approach. As when you begin with just 10% and keep tacking on things for edge cases, you tend to get a crummier solution in the end than you otherwise would have. But that's why refactoring is a thing right? Oh wait, management is against that because they don't acknowledge technical debt...

Let me just slip this in here: https://www.youtube.com/watch?v=P4VBqTViEx4

I like this one from ChromeOS about boot decisions.

https://www.chromium.org/_/rsrc/1277241373652/chromium-os/ch...

Somewhat related: in spite of this complexity, Slack desktop is missing options in closely related functionality. The only way to avoid a visible badge appearing on a slack workspace is to sign out entirely, which lands you in the tire fire of trying to reauthenticate to a slack.

So you can silence notifications, but unless you're good at ignoring those little red dots, you'll still be distracted.

That Slack chart is horrifying because unlike most cases of "features are more complicated than they appear", everything in this chart is user-facing. No Slack user is going to be able to follow all of this to know for sure how exactly their notifications get filtered.

I agree with you. I’m actually quite excited to see that chart, because now I might be able to figure out why I often don’t get messages sent to my phone, but the show as unread when I get back to the computer...

If you're still "active" on the computer it notifies you there and doesn't think it needs to also reach you on mobile. But I think you can set your mobile notifications to notify anyway.

Discord is nice with this and if your desktop goes idle without you reading messages it then pushes them to your phone. It’s one of the best features I haven’t seen in many other products. Particularly as it mutes your mobile notifications when you are on desktop. Which a lot of products also get wrong.

I think the elegance is that all of this logic boils down to a few user inputs (global + channel notification prefs) and overall everything ends up feeling pretty intuitive.

That’s just my opinion as a Slack user but as someone who’s worked on notification and badge systems I appreciate the honing that’s been done here.

It's convoluted because it's expressed in an incomprehensible way. Make it a Petri net or something, first decide what is the class of the message & pref of that class and it's 3x simpler.

And still people use @here or @channel without good reason. Every time I see this I'm reminded that social problems don't have technical solutions, not that that the technical solution was clever.

So is it a solution to a problem or is it just papering over a completely different problem?

Nice. The fact that it can be described by a diagram that fits on a single screen and could be absorbed by a new hire in 20 minutes is neat.

I wonder if there are ways to design software such that we can get visualizations like this generated from the code "for free". It could definitely be really useful when diff'ing code, or even just for general communication in meetings etc...

Perhaps there are some academic/esoteric languages that do things along those lines?

Did a quick search and found code2flow. Seems to be a cloud tool, where I have to upload my code.

I'm more interested in an open source tool, that can run locally with TypeScript.

Anyone knows a tool/package?

This was actually less complicated that I had expected it to be.

I think the example still works because, while it is not too complicated to understand, it is also non-trivial. It's also probably more complicated than the typical non-technical person would think.

It's also worth mentioning that this diagram doesn't capture dataflow or the relationships between the subsystems needed to make this work. The logic for notifications requires interaction with user preferences, channel membership, comment parsing, thread management, and more[0].

All told, you may still be looking at (low) thousands of lines of code, with maybe 1.5-2x times that amount for test code.

[0] I'm just guessing how the app is structured internally. I have no idea what it is actually like.

It's also like 3 years old. Would love to see what it looks like now.

It's like never true, it does not show that you can't get email notification faster than in 30 minutes.

Also now should include adding random old stuff to notification.

Things like notifications have pressure on them to be simple, because users want to be able to decide when they will receive notifications, which means it needs to be easy for them to understand when they will and will not receive them with particular settings. I'm sure there are examples of some non-user-controlled decisions that have much more complicated flow charts.

Yes, it was something I'd never thought of before, but definitely simpler than I guessed before I clicked the link. That said, each time you add a conditional, you need to be increasingly careful about where you put it, and what other impacts it has.

I would also imagine that there are a variety of other features which require similar flow charts.

Yes, this is what my co-workers refer to as an if-statement.

All programming is just if statements. That doesn't mean systems can't be complex.

If you're creative you can get away without conditional branches: http://www.jucs.org/jucs_2_11/conditional_branching_is_not/R...

Not true; if the conditional branch goes backward then it's a (possibly do-) while statement. Also subroutine calls.

Counternitpick: Those subrouting calls and while statements are compiled to conditional jmps. If you squint your eyes it's just a fancy 'if'.

"It's no use, @a1369209993 - it's IF statements all the way down!"

Apologies to William James' apocryphal quote.

This is not about how it translates into code. I see a lot of value in this diagram when compared to the half-assed "requirements" most PMs put in their JIRA tickets.

That is my takeaway: PMs and non-developers - you must think through the entire workflow. When you don't, your engineers will and will either pepper you with questions that you are not prepared for or they will decide for you.

As an engineer, I consider fleshing out incomplete workflows to be one of the largest parts of my job. I've found the technique of saying "hey, the specification doesn't mention what to do in this situation, based on X/Y/Z elsewhere in the specification / this other similar feature, I'm operating under the assumption that it should work like <description of your best guess>. Let me know if that's mistaken". Then I make sure I have a commit of the state of the code, and start building based on the stated assumption.

A large fraction of the time, the PM just goes "that is correct", and the spec / ticket / whatever gets updated. When the answer is not "that is correct", you do lose out on whatever work you've done since sending that message, but writing code you eventually throw away isn't the end of the world. Also "that is not correct" responses often highlight areas where either the developer misunderstood what the PM was envisioning or the PM has a misunderstanding of what the system can do or how their proposed feature interacts with something else.

For this to work, you need:

1. Some variety of asynchronous channel that the developer can push stuff into at whatever frequency they want, and that the PM periodically catches up on entirely.

2. The developer to have a working understanding of how existing systems work and the system as a whole, from the business level.

3. The flexibility to modify specifications between the initial conception and implementation.

If you have all of those things, the PM doesn't necessarily need to think through the entire workflow beforehand -- it's nice if they can do that, but you can still ship working features without that and sometimes that is the pragmatic way to do it.

I'm exactly on the same page, this is uncanny!

If you've thought about the entire workflow, all edge cases and the spec is 100% complete then you've written code, it's just a matter of whether humans or machines will compile it.

I find myself creating a lot of these diagrams to share with PMs (along with sequence diagrams, system architecture diagrams, decision tables, etc.).

Systematically articulating all of these different conditions isn't necessarily the strong suit of a PM, but they're generally quite capable of understanding and providing input to such documents.

I mean, the chart is still useful to have, and it'd be a couple of methods probably had I written it. But it's not a huge state space, and most of the transitions are fairly reasonable.

I can imagine it was quite a lot of work to come to such a clean and relatively simple chart.

Coming up with this chart from a generic ticket like "impl notifications" is one of the hardest parts of being a developer.

Code is generally the easy part once you know exactly what you're doing.

> one of the hardest parts of being a developer.

Not least because it's really the product designer and product owner's job to make this kind of chart.

Which they never do to a satisfactory level (in my experience). So it still falls on the developer to do it properly, then PO just copies it for their presentations.

The "User in DnD?" box made me chuckle.

For other readers (like me) who were confused for a few seconds (maybe because I don't use slack?): Do not Disturb.

Because they're playing Dungeons and Dragons.

Butterfield hasn't graduated to Advanced Dungeons & Dragons yet? About time.

Do not disturb.

Yeah, I got burned by Slack recently.

I expected mobile notifications to fire no matter what... but they will only fire if you are not on any other client (desktop) and if the app is not running on the foreground.

According to that chart you have to change your Mark as Read setting... who knows where it might be though

There's a top-level tab called "Mark as Read" in the preference pane.

The equivalent of this for sending a text message through the telco I dribbled with is the 4500 line nested if-clause in the 65k COBOL source file.

Then for each check its a tour into another 60k beast with the main flow in a much handier 2k loc if-clause. And actions to be done are sent relatively straight forward from there, where needed.

But its OK, avoiding objects isn't too bad, its but after 30 years a lot of things in flows get added multiple times out of fear of breaking stuff, and it adds visual bloat.

Recently we tried to start using Slack for our local sporting club. We added our club google account to access files but this account also had all members in mailing group or something like that. Little bit after we added that account all 60+ members started receiving slack notifications and tens of them. Probably we hit some edge case that is not covered in the fow chart.

Nice! My PM and I put together a few flowcharts for a feature last week which made it much easier to implement (otherwise it was just a jumble of words on paper).

Not mentioned in this flowchart is that sometimes one element of the flowchart breaks previous assumptions and required refactoring a bunch of code. Oh well!

It's pretty good that they even have this flowchart...

It looks like maybe a page of code / if statements.