To OP's point of "features are more complicated than they appear" I always like to point to the flowchart of Slack's notification logic.
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.
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
https://www.chromium.org/_/rsrc/1277241373652/chromium-os/ch...
So you can silence notifications, but unless you're good at ignoring those little red dots, you'll still be distracted.
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.
So is it a solution to a problem or is it just papering over a completely different problem?
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?
I'm more interested in an open source tool, that can run locally with TypeScript.
Anyone knows a tool/package?
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.
Also now should include adding random old stuff to notification.
I would also imagine that there are a variety of other features which require similar flow charts.
Apologies to William James' apocryphal quote.
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.
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.
Code is generally the easy part once you know exactly what you're doing.
Not least because it's really the product designer and product owner's job to make this kind of chart.
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.
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.
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!