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.
Yup, I’ve always referred to UML as ‘a formal standard for back-of-the-envelope sketches’. It demands too much precision and rigor to be used during the early parts of a project when you want to just get people on the same page about roughly how things should be structured without baking in assumptions too early. Then in the later part of a project when you’re talking about modifying an existing system, reexpressing the existing semantics accurately in UML first demands unnecessary pedantry.
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.
I learned UML years ago but found PowerPoint superior for explaining what needed to be done. So much easy to sketch using PPT than even Visio which makes me pull my hair out.
> 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.
Same here. I still think UML is a great tool, but few have the need to follow the standard to the letter. Often I don’t fully understand a problem before poking at it for a while.
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.
