Standardised UML was never something for me, sketching diagrams loosely inspired by UML definitely was.
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.
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).
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.
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.
Because UML is usually used when you don't yet know or decided many details.
If you put them on diagram they will often turn out to be wrong, or even worse - artificially restrict the implementator's freedom for no reason.
"Why do we require 10 clicks to upgrade the subscription plan?"
"Because that's how it was specified"
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)
* Can be verified formally
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.
Instead, I spend 70% of the time just trying to figure out a good diagram approach.
When you draw a diagram to communicate something about a system, being able to choose which things are important to you right now and which things aren’t is a feature of informal diagramming, not a bug.
> Explanation should do things that the other parts of the documentation do not. It’s not the place of an explanation to instruct the user in how to do something. Nor should it provide technical description. These functions of documentation are already taken care of in other sections.
Where UML goes wrong is that it tries to be a very detailed technical description. Usually, you just want a reference guide for that sort of thing. And reference docs are rarely maintained manually, at least not with any accuracy. I've yet to find a good system that can generate diagrams for technical reference that's usable.
It's hard to say what fits and what does not in a diagram, because it depends on the point you're trying to make. But I usually find that "explanations" are really tricky to get right. UML's a handy place to start thinking, but you're almost always going to cut out a lot of detail to make an explanation easy to understand.
I put the bare minimum of time into studying UML, and I'm glad I did.
As I write this I can’t help wonder if perhaps it would be useful to return to UML after doing some exploration and before starting the real implemention. Still everyone on a project would need a refresh on UML, most of us forgot most of the details.