This is the real answer. The effects of UML will live on forever, but a formal language for it has been dead for a long time in common use, though some of course will still use the exact formality.
The value of UMLish things is just visually diagramming data and systems. Boxes with arrows and some data inside is typically enough to do the trick. Lucidchart is thriving despite many not actually writing explicit UML on it.
Why is this sentiment so prevalent. I'm thinking more and more that simplistic and vague informal diagramming is a great source of confusion.
UML, specifically statecharts capture a lot of behaviour unambiguously, though it is hard to draw by hand (due to its hierarchical nesting possibility, so some kind collapse/expand system is required to draw them in a sane manner).
I don't find it a source of confusion, because my boxes and lines diagrams are explicitly meant to be sketches, and are presented as such.
UML, as others have said, is both too precise about things that are still vague at sketch time and took vague about things I want to be precise about to be useful. And once I have a real system, the real complexity in the system always makes for either an insanely huge diagram with lines everywhere, or an imprecise one full of lies and omission.
Trying to program with UML is basically like trying to write a system of 10k lines by first writing them all down, and only then beginning to try to compile it. It's not going to produce good results, not just because of the endless little errors, but especially the big ones that your could have discovered much sooner if you were using something more real than UML. UML is superficially easier to work with than direct code, but in depth, I think inferior to it.
Some of the notation is sometimes useful, but to use it as intended is crazy.
> simplistic and vague informal diagramming is a great source of confusion
It definitely is, but are UML statecharts the right solution? Why not go the full nine yards and use a full-blown formal modelling environment, like TLA+? After all, using UML in a formal fashion would take more or less the same amount of effort as learning TLA+, which moreover:
* Is textual (making it easier to version-control and collaborate upon)
Because the more mathematically rigorous and pure a description is, the more likely that your programmers won't carefully read the spec, or won't fully understand the exactly meaning of the UML arrows.
It doesn't help that every UML diagram I've ever seen is ugly. There are always way too many jagged lines, and seemingly random attachment points. (Example: https://tallyfy.com/wp-content/uploads/2018/02/Class-Diagram...). In the little triangle, one line goes straight down, and one goes to the side. Is going to the side special? Or just a random artifact of the diagram? Without being an expert, it's hard to know.
With written-language descriptions, it's easier to be rigorous enough for all programmers.
In my experience (startup product development), product requirements and constraints are constantly shifting in order to support new use cases. In my practice, that has translated into only formalizing specifications after the fundamental needs of a system are set in stone, which is usually after release. When I’ve worked on contract-based projects, it’s been much easier to formalize beforehand, but I suspect most developers on HN are involved in active product development.
Thats true, but at least before implementation, the behaviour to be implemented should be known to some extent. UML Statecharts remain a good method to document behaviour.
The reality is that humans have a rough sweet spot for the amount of complexity they can reasonably consume, and a high-level, somewhat vague diagram that has been cherry picked by someone who intimately knows a system is a great introduction.
This is not to say that blueprint-style UML has no value, it's just comparatively rarer, since it requires much more time investment. However, the two do not address the same needs.
I've been trying to build diagrams to familiarize myself with new systems, but I wish there was a UML-lite that worked well for generalized diagrams in Python.
Instead, I spend 70% of the time just trying to figure out a good diagram approach.
The value of UMLish things is just visually diagramming data and systems. Boxes with arrows and some data inside is typically enough to do the trick. Lucidchart is thriving despite many not actually writing explicit UML on it.