The author got very close, but missing the forest for the trees.
What a diagram really needs is a purpose. A clear need for the information to be conveyed.
Who's to say that unlabeled arrows are a bad thing? Or that there's too much on a diagram? That depends on how it's used! What it's for.
Adding context and explainers is certainly a Good Thing, but again, without an overarching reason for the diagram to even exist - who cares?
Diagrams are a communication tool. No more, no less. The vast majority aren't up-to-date, complete or even completely accurate; for the same reason roadmaps aren't, let alone the map of the London Underground.
> Diagrams are a communication tool. No more, no less. The vast majority aren't up-to-date, complete or even completely accurate...
In industrial process engineering, diagrams of process flow and instrumentation are literally part of "The Plan". They are included with architectural, mechanical, and electrical drawings; signed of by professional engineers and jurisdictional authorities; and passed to contractors to build. If there's a need to deviate from "The Plan", it gets documented and then a revision is created.
It has always surprised me how software as an industry gets away with sketchy documentation
Customers don't even know how their systems work, and only discover the edge cases they had handled in the old system when they discover it suddenly not working in the new system, and so on.
When I ask customers "does X ever happen" and they say "no, never", I now assume that means "possibly, but seldom". If I need to make sure, I drill them hard on it.
I've been in meetings where a line manager doesn't know that one of the workers they manage performs a critical business operation daily, without which the whole thing would grind to a halt. That's one level up. No wonder those who decide, many levels above that, have no idea and get it wrong.
I never worked anywhere that was truly waterfall and I've been in the industry for almost 30 years. The best projects I worked on have been iterative with some sort of upfront design phase for each iteration, where an "iteration" was a large chunk... like a couple months... You might hear this referred to as the "spiral" model. There are many shades of gray between "waterfall" and true "agile" and I'd argue that neither extreme actually works.
I have been involved in numerous "waterfall" software projects and the majority were successful. This is because the "waterfall" process was never as the Agile proponents describe it. Successful "waterfall" projects are always iterative.
For me it’s primarily a tool that aides and shapes my thinking. I start sketching out diagrams to discover dependencies, edge cases, and so on. Most of what I draw I don’t share.
Even during brainstorming sessions I’ve found immense use of diagrams, they cut out so much noise.
What a diagram really needs is a purpose. A clear need for the information to be conveyed.
Who's to say that unlabeled arrows are a bad thing? Or that there's too much on a diagram? That depends on how it's used! What it's for.
Adding context and explainers is certainly a Good Thing, but again, without an overarching reason for the diagram to even exist - who cares?
Diagrams are a communication tool. No more, no less. The vast majority aren't up-to-date, complete or even completely accurate; for the same reason roadmaps aren't, let alone the map of the London Underground.